Chapter 1 of 9
The pieces: brokers, logs, and replicas
Producer
checkout API
appends to topic
orders
Partition
orders-7 · one replica per broker
consumer reads
One category: systems where producers append ordered records to a replicated log, stream, or durable queue, and the system decides when a write is committed. (Databases like Postgres or Cassandra replicate mutable rows instead, a different problem, so they are not in this table.)
| System | Safe replica set | A write is durable when | Relation to Kafka |
|---|---|---|---|
| Kafka | ISR (in-sync replicas) | acks=all and at least min.insync.replicas acknowledge |
the baseline |
| Redpanda | Raft majority | a majority commits the entry (Raft) | same Kafka API, Raft instead of ISR |
| Pulsar / BookKeeper | BookKeeper ack quorum | the ack quorum of bookies acknowledges | serving split from storage (ledgers) |
| NATS JetStream | Raft majority | a majority commits the entry (Raft) | lighter weight, subject-oriented |
| RabbitMQ quorum queue | Raft majority | a majority commits the entry (Raft) | queue semantics, not a replayable log |
| Amazon Kinesis | hidden, AWS-managed | AWS accepts the record into the shard | same stream API, internals sealed |
It all comes down to one question
Not "did the leader receive the write?" but "how many replicas accepted it before the producer was told success?"
- ISR = which replicas are caught up enough to count
acks=all= wait for the whole safe set, not just the leadermin.insync.replicas= the minimum that must hold it before success- Raft majority (Redpanda, JetStream, RabbitMQ) = commit after a majority replicates
- ack quorum (Pulsar / BookKeeper) = commit after the ack quorum replicates
- Kinesis = the same shard and stream API, with replication sealed inside the service
Learn the Kafka column here and the rest are renames: swap "ISR" for "majority" or "ack quorum" and the commit rule is the same idea.