✏️ Explanatory Question
Estimate the read to write ratio from the product's behaviour, then sanity-check it with a rough calculation rather than asserting it.
How to work it out: take the number of active users, multiply by how often each performs the action per day, and compare. For Twitter-like scale, 200 million users reading a timeline 10 times a day is 2 billion reads, while 10 million posts a day gives a ratio near 200:1. The precise number does not matter - the order of magnitude does.
Why it matters
Read heavy pushes you towards caching, CDNs, read replicas, denormalisation and precomputed feeds. The governing idea is that you can afford to make writes expensive in order to make reads cheap - fan-out on write is exactly this trade.
Write heavy pushes you towards horizontal sharding by key, LSM-tree stores such as Cassandra or RocksDB that turn random writes into sequential ones, batching, write-behind caching, and queues such as Kafka to absorb bursts and decouple ingestion from processing.
An important caveat about replicas. Adding read replicas does not increase write capacity, because every replica must apply every write - so the write throughput ceiling stays roughly where it was, and replication lag grows as the leader saturates. Replicas relieve read load, not write load. The only real answers for write scaling are sharding the write path, batching, or reducing what you durably store at all - for example, keeping high-frequency location pings in memory and persisting only periodic checkpoints.
Also ask about the peak. A system that is read heavy on average can be write heavy for ten minutes during an event, and it is the peak that breaks things.
Sign in to save your progress and continue exactly where you left off.