Foundational cases: numbers and config reading
Read real capacity math and config from the four cases, then do the arithmetic: a quorum overlap check, a shortener QPS/keyspace estimate, a crawler bloom-filter sizing, and a Kafka partition-count calculation.
Design bugs hide in the numbers, not the prose: a quorum that doesn’t overlap, a QPS that’s off by 10^5, a bloom filter sized for the wrong error rate, a partition count that caps throughput. Read each snippet, do the arithmetic in your head, and pick the answer a senior engineer would commit to.
Practise the loop you run during a design review: locate the numbers in the config, apply the rule (quorum overlap, daily-to-QPS, bloom-filter bits, partition throughput), and choose the change the arithmetic actually supports.
Snippet 1 — the quorum config
# distributed KV store
replication_factor_N: 3
write_quorum_W: 1
read_quorum_R: 1
# "tuned for low latency"With this config, can a client always read back a value it just wrote on a strict quorum, and what's the fix if not?
Snippet 2 — the shortener estimate
def shortener_capacity(new_urls_per_month: float, read_write_ratio: float = 100):
writes_per_sec = new_urls_per_month / (30 * 86_400)
reads_per_sec = writes_per_sec * read_write_ratio
return round(writes_per_sec), round(reads_per_sec)
# 100 million new URLs/month
print(shortener_capacity(100_000_000))Roughly what does shortener_capacity(100_000_000) return, and which number drives the architecture?
Snippet 3 — the bloom-filter sizing
# crawler seen-URL set
exact_set_urls = 10_000_000_000 # 10 billion seen URLs
bytes_per_url_exact = 100 # ~100 bytes/URL stored exactly
bits_per_url_bloom = 10 # ~1% false-positive target
exact_ram_bytes = exact_set_urls * bytes_per_url_exact
bloom_ram_bytes = exact_set_urls * bits_per_url_bloom / 8Roughly how much RAM does each approach need, and what does the bloom filter cost you?
Snippet 4 — the Kafka partition count
# Kafka-like topic sizing
target_throughput_mb_s = 1000 # ~1 GB/sec at peak
per_partition_mb_s = 10 # ordered, replicated write ceiling per partition
consumers_in_group = 8
partitions_needed = target_throughput_mb_s / per_partition_mb_sHow many partitions does this topic need, and what's the consequence for the 8-consumer group?
- 01How do you check a quorum config gives read-your-write, and what's the trap?
- 02How do you size a crawler's bloom filter, and how many Kafka partitions for a throughput target?
Every design decision in these cases reduces to arithmetic you read straight off the config. The quorum check is R + W > N: a config of W=1, R=1 at N=3 sums to 2 ≤ 3, so reads can miss writes — fix with W=2, R=2. The shortener estimate converts 100M URLs/month to ~40 writes/sec and, at 100:1, ~4,000 reads/sec — and the read number is the one that drives the cache-and-redirect architecture. The bloom-filter sizing shows ~10 bits/URL gives ~12.5 GB for 10 billion URLs versus ~1 TB exact (~80x smaller), at the cost of a small false-positive rate. The partition count is target throughput ÷ per-partition ceiling (1000 ÷ 10 ≈ 100 partitions), which also caps consumer parallelism at the partition count. The senior habit is the same across all four: find the numbers, do the math, watch the units, and pick the fix the arithmetic supports — not the one that hides it.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.