distributed systems
9 minDistributed Systems Foundations: Consistency, Retries, and Delivery Semantics
Separate consistency guarantees from delivery guarantees and design for the partial failures that make retries necessary.
Search the library
14 matching resultsArticles and interview answers
distributed systems
18 minDistributed Systems Advanced: Rebalancing, Sagas, Consensus, and Trace Context
Design around Kafka group churn, payment idempotency, coordination limits, sagas, CQRS, and context propagation across async boundaries.
Q&A
Q&AWhat does vector-clock incomparability represent?
Concurrent histories under the vector clock identity and propagation model.
Read the concise answer
If neither vector is component-wise less than the other, neither history contains all represented knowledge of the other. This does not establish physical-time order or choose a globally agreed winner.
Q&A
Q&AWhere must a fencing token be enforced?
At the destination, atomically with the protected effect.
Read the concise answer
The destination rejects generations older than its highest accepted token. A lease does not stop a paused worker, and a fence cannot reject an expired generation it has not yet learned is superseded.
Q&A
Q&AHow does a transactional outbox make event publishing reliable?
Persist the business change and an event record together, then publish the event asynchronously.
Read the concise answer
A database transaction writes both the business state and an outbox row. A separate publisher retries delivery from that durable row. This avoids the gap where a database commit succeeds but broker publication fails. Delivery can still be repeated, so consumers should deduplicate by a stable event ID.
Q&A
Q&AWhat changes with acks=all and min.insync.replicas=2 during a broker partition?
The producer may reject writes when fewer than two replicas remain in the in-sync set.
Read the concise answer
With three brokers and min.insync.replicas=2, acks=all requires the current in-sync replica set to meet the minimum. If the ISR falls to one, writes are rejected rather than acknowledged with reduced replication. acks=1 favors availability but risks losing leader-only writes if that leader fails before replication.
Q&A
Q&AHow do you prevent Kafka CommitFailedException when processing is slow?
Keep consumer liveness within max.poll.interval.ms and commit only after durable work.
Read the concise answer
If processing exceeds max.poll.interval.ms, the group may consider the member failed and reassign its partitions; a later commit from the old generation is rejected. Reduce records per poll, process with bounded workers while preserving partition ordering, pause/resume appropriately, or adjust the interval based on measured worst-case work. Keep the fix from merely delaying failure detection indefinitely.
Q&A
Q&AWhy are Kafka offsets and commit timing so important?
Offsets are the durability checkpoint. Commit too early and you lose work; commit too late and you duplicate it.
Read the concise answer
Kafka commits represent when the consumer believes work has been finished. If the offset is committed before the business effect is truly durable, a crash can lose data. If it is committed only after a delay, the application may re-process messages when the consumer restarts. The correct strategy is to commit only after the state change is stored successfully and the work is idempotent enough to recover from retries.