Replicated Log
A replicated log makes an ordered history available on several nodes.
- Ordered prefixCommitted entries form the same authoritative history for the promised ordering unit.
- Commit indexSeparates replicated or proposed entries from the committed prefix.
- Catch-upA returning replica reconciles missing entries and discards uncommitted divergence.
Context
Why this is important
Its value comes from a precise commit rule and tested behavior during partition and leader change.
This profile covers the distribution mechanism. The three-node order stream is a hypothetical extension; the current shop has seven modules and one shared database.
Replicated log: states of an entry
The current shop remains a modular monolith with seven modules and one shared database. For a hypothetical standalone order stream, a leader writes each order to a replicated log with three nodes. The platform acknowledges an entry only after the configured majority has stored it durably and marks the committed index. The team isolates a follower, performs a leader change, and proves that the committed prefix remains intact and the returning follower catches up without duplicate business effects.
This is how you read the picture
- Ordered prefix Name ordering per log or partition
- Commit index Apply only the committed prefix
- Catch-up Observe lag and conflict repair
| Comparison | Stage | Proof | Open question |
|---|---|---|---|
| Written on leader | Local log position exists | Leader holds the entry | Does it survive leader failure? |
| Quorum acknowledged | Commit rule satisfied | Entry belongs to committed prefix | Has the application processed it? |
| Consumer acknowledged | Business effect and position stored | Restart is testable | Are duplicates idempotent? |
Benefits & limitations
Helps if:
- A replicated log fits when several nodes must follow the same committed change history.
- It fits stateful platforms that replay entries after failures and allow replicas to catch up.
- Partitioned logs fit when per-key ordering is sufficient and horizontal throughput matters more than global ordering.
Boundaries
- Majority acknowledgement increases latency and protects only against the failure model assumed by the protocol.
- Replication lag permits stale reads; read preference and consistency guarantee must align.
- An ordered log entry is not yet a business effect. Consumers must handle repetition, correlation, and faulty entries.
In practice
- Compare the latest committed log position on the primary with the replica. Determine when customer service could read a stale payment view.
- Interrupt the link between replica and primary. Check lag, resumption, and the acknowledgement rule before a failover occurs.
- Weigh synchronous against asynchronous acknowledgement for payment status. State the expected write latency and accepted loss window explicitly.
Read the detailed explanation
A leader or consensus procedure orders new entries. Replicas store them in the same order; only the specified acknowledgement rule advances the commit index and makes a prefix committed.
A replica can lag, receive entries again, or discard a divergent uncommitted suffix after a partition. Applications must therefore assume only the promised ordering unit, such as per partition rather than globally.
Consensus explains majority decisions and leader changes; Replication covers copies, lag, and read behavior. A replicated log is a mechanism from which a state machine or event broker can be built.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
What does the commit index mark?
View the solution with justification
The prefix committed under the specified replication rule.
ApplyingTransferred to a new situation
What does the leader change test in the shop scenario?
View the solution with justification
That committed order entries remain and uncommitted divergence does not appear as a business effect.
EvaluateWeighing an alternative
Why is “replicated three times” insufficient?
View the solution with justification
It states neither acknowledgement rule and failure model nor ordering unit and read behavior.
Explore further
These building blocks continue the thoughts of this page.
References
- PostgreSQL · Warm Standby (opens in new tab)Primary documentation relevant to Replicated Log.
- Apache Kafka · Design (opens in new tab)Primary documentation relevant to Replicated Log.
- Raft · In Search of an Understandable Consensus Algorithm (opens in new tab)Primary documentation relevant to Replicated Log.