Back

How Fluxzero keeps
products running.

Read this when you want to understand why Fluxzero can take responsibility for running your product, and what makes those guarantees hold.

Your applications connect outward
to one isolated cloud.

Every running instance opens its own outbound connection to Fluxzero. Add more instances or split a product into more applications without giving them public endpoints or creating network routes between them. The work that keeps them running stays in one shared cloud, inside a cluster isolated from other customers.

Your isolated cluster
Application A
Application B
Fluxzero cloud
State Delivery Recovery Security Scale
Three instances of application A and two instances of application B each connect outward to one Fluxzero cloud inside an isolated customer cluster.

Requests survive
application restarts.

An incoming request is recorded before an application is asked to handle it. The application reads from that record and stores its progress separately. If the process disconnects, the request stays available and work resumes from the last completed position.

Received
Recorded
Restart
Handled
The request remains in the durable record while the application restarts.

Two buyers cannot reserve
the same ticket.

When a ticket is modeled as one resource, competing commands are checked against the same current state. Only a legal change can commit. After the first reservation changes the ticket, a second reservation cannot commit against the old state.

Buyer A
42Ticket
Buyer B
Reserved
Rejected
A single commit boundary prevents both buyers from reserving ticket 42.

Slow work does not hold up
unrelated work.

Different kinds of work can follow the same recorded events while keeping their own progress. A slow search index can stop without holding up the product or an integration. When it returns, it continues from its own position.

Recorded events
Product
Search
Integration
The search workload pauses without stopping product handling or an integration.

Heavy work can scale
on its own.

Work is divided into stable lanes. Messages for the same resource stay ordered in one lane, while unrelated resources can run in parallel. More instances can claim different lanes, so heavy work can receive more capacity without changing the product code or scaling everything else with it.

Heavy work
4 workers
The heavy workload fans out over four independent workers.

Failed work can be fixed
and replayed.

A failed handling attempt is stored with the original message, its cause and its position. After the handler is fixed, a selected range can be replayed while normal processing continues from where it was.

  1. 1
  2. 2
  3. Failed
  4. 4
  5. 5
Fix
Replay
The failed third item is fixed and replayed without moving the live end of the timeline.

Sensitive data can disappear
from recorded history.

The application marks a protected field once. Fluxzero separates its value from the recorded message and leaves a reference in its place. The value can be restored while the application needs it, then removed so later reads only see the redacted reference.

Order 42 size  M email
Remove
Order 42 size  M redacted
The protected email value is removed while the non-sensitive order history remains.

Your application can stay off
the public internet.

Public HTTP and WebSocket traffic ends at a managed cloud entrance, where identity and access rules can run before a request becomes recorded work. The application connects outward to receive it, so the standard hosted path needs no inbound application port.

Public
Cloud entrance
Applicationoutbound
The cloud entrance receives public traffic; the application remains behind the boundary and connects outward.

Traffic cannot create unlimited work
inside your application.

Fluxzero keeps explicit limits on work that is waiting or in progress. When capacity is full, more work is held back or rejected instead of growing an unbounded in-memory queue. Capacity can then be added to the workload that needs it.

Capacity
Application
Held back
Only bounded work enters the application; excess incoming work is held back.

You can answer what is true now
and how it got there.

Fluxzero keeps the events that changed a product and the current state built from them. The current state can be filtered and searched, while correlation data connects a request to the commands, events and results it caused.

NowTicket 42Reserved
  1. Created
  2. Held
  3. Reserved
The current reservation state is linked to each recorded change that produced it.

Technical references

The developer documentation describes the contracts, configuration and application APIs behind these behaviors.