ARCHIVED from builddistributedsystem.com on 2026-04-28 — URL: https://builddistributedsystem.com/tracks/store/tasks/task-7-3-read-consistency
TASK

Implementation

Implement linearizable reads:

Option 1: Log reads (simple but slow)

  • Treat reads as log entries, wait for commit

Option 2: ReadIndex (Raft optimization)

  • Record current commit index
  • Confirm still leader (heartbeat round)
  • Wait for commit index to be applied
  • Execute read

Option 3: Lease (fast but clock-dependent)

Sample Test Cases

Read via log is linearizableTimeout: 5000ms
Input
{
  "src": "c0",
  "dest": "n1",
  "body": {
    "type": "init",
    "msg_id": 1,
    "node_id": "n1",
    "node_ids": [
      "n1"
    ]
  }
}
Expected Output
{"src":"n1","dest":"c0","body":{"type":"init_ok","in_reply_to":1,"msg_id":0}}

Hints

Hint 1
Simple: reads also go through log
Hint 2
Optimized: confirm leadership before read
Hint 3
Lease-based: use time bounds
OVERVIEW

Theoretical Hub

The Stale Read Problem

A leader might be partitioned and not know it. If it serves reads from local state, it returns stale data. Linearizability requires that reads reflect all prior writes.

ReadIndex

Before serving a read, confirm you are still leader by getting acknowledgment from a majority. Then wait for the commit index at that moment to be applied. This ensures linearizability without logging reads.

Key Concepts

linearizable readsread indexlease
main.py
python
Ensure Read Consistency - The Store | Build Distributed Systems