distributed systems / LEVEL 4

The offset committed before the balance

EST.50 MIN

THEORY / RETRIEVAL

What to restore

Use a stable event id independently of partition offsets
Apply business state and inbox evidence atomically
Keep ordering state scoped to a partition key

Kafka orders records only inside a partition

A partition key should follow the aggregate whose order matters, such as account_id. More partitions increase parallelism but cannot provide one total order. A versioned message contract needs event id, schema version, aggregate id, occurred time and enough data for deterministic handling.

Offset progress and business progress differ

Committing an offset before the database effect can lose work; committing after can replay work. A consumer therefore makes the business change idempotent, commonly by storing event-id inbox evidence in the same local transaction as the effect, and advances offsets only after that transaction succeeds.

CHECKPOINT

A consumer commits its offset after the database transaction, then crashes before receiving the commit response. What should make replay safe?

Confidence: 3/5

02 / DEBUGGING

Find and fix the defect

Repair the consumer state transition. Reject negative or non-increasing offsets per partition, deduplicate globally by event id, and check balance overflow before mutating inbox, balance or offsets.

Initializing editor…

CLOUD SANDBOXnetwork off · 256 MB · 12 s

1 / 64 KB

OUTPUT

Runner is waiting for a submission.