I use the write ahead log idea whenever recovery matters. Before state changes are trusted, I want a durable intent record the system can replay after a crash.
The log is the recovery truth
I use this section to force the failure case into the conversation, not just the clean path.
A database can append a log entry, flush it safely, then update indexes or pages later. If the process crashes halfway through, recovery reads the log and finishes or rolls back the work correctly.
Database recovery example
The reason I use a concrete scenario is simple: it exposes the part of the design a team will actually have to operate.
A broker receives a message. It writes the message to the log before acknowledging the producer. After a crash, the broker replays the log and does not lose the acknowledged message.
Append before apply code
I use the code here to show the decision boundary, not just syntax.
Acknowledge only after the intent is durable:
void handle(Message message) {
log.append(message);
log.flush();
state.apply(message);
producer.ack(message.id());
}The handler flushes the log before applying state and acknowledging the message. If the process dies, the log is the source used to replay safely.
Sequence diagram: log before acknowledge
The acknowledgement is safe because recovery can find the message in the log.
The durability rule
- Acknowledge only after the durable point that matches your promise.
- Monitor log flush latency and disk pressure.
- Test recovery by replaying real logs in lower environments.