FFORGE//RS
← Roadmap

distributed systems / LEVEL 4

The order committed, the event vanished

EST.45 MIN
01

THEORY / RETRIEVAL

What to restore

  • Explain why a database write followed by Kafka publish is not atomic
  • Persist domain state, idempotency evidence and outbox event together
  • Make repeated commands side-effect free

Two successful APIs do not make one transaction

If a service commits order state and then publishes to Kafka, a crash between those operations loses the event. Publishing first creates the inverse failure. A transactional outbox stores the state change and an event record in one local database transaction; a relay publishes committed records later.

At-least-once requires identity

The relay may publish again after a timeout or crash, so events and commands need stable identifiers. Consumers keep inbox evidence or perform naturally idempotent upserts. Exactly-once marketing does not remove the need to define the application's atomic boundary.

CHECKPOINT

Why does retrying `UPDATE orders; publish Kafka event` not close the failure window by itself?

ISOLATED RUST 1.96
src/lib.rsEDIT

02 / IMPLEMENTATION

Implement the contract

Implement the in-memory transaction model. A valid first command must update the order, record the command id, and append exactly one versioned outbox event. Replays return Duplicate without mutation; invalid or overflowing commands leave all collections unchanged.

Initializing editor…
CLOUD SANDBOXnetwork off · 256 MB · 12 s
1 / 64 KB
OUTPUT
Runner is waiting for a submission.