Key DE Numbers: The Back-of-Envelope Cheat Sheet
Interviewers do not expect you to recite AWS invoices. They expect you to reach for a number, say where it comes from, and reason from it: "a partition does tens of MB per second, we need 300, so we are looking at low tens of partitions." Getting the order of magnitude right, out loud, is the whole game. Precision to two significant figures is plenty; being off by 1000x is what sinks you.
This is the set worth carrying into the room. Round everything. The point is arithmetic you can do on a whiteboard, not accuracy you would defend in a capacity-planning doc.
The latency ladder
Every design trades latency for cost or freshness. Know the rungs so you can say why a step is slow and what moving it would cost.
| Operation | Rough latency | Reason it matters |
|---|---|---|
| L1 / L2 cache reference | ~1-10 ns | Free, for practical purposes. |
| Main memory reference | ~100 ns | Why in-memory joins and caches win. |
| Read 1 MB sequentially from RAM | ~5-10 us | Scanning memory is effectively instant. |
| SSD / NVMe random read | ~16-100 us | Random reads are fine on flash, not on disk. |
| Datacenter network round trip | ~0.5 ms | The floor on any same-region service hop. |
| Read 1 MB sequentially from SSD | ~0.2-1 ms | Columnar scans live here. |
| Disk (HDD) seek | ~5-10 ms | Why small random reads on object storage hurt. |
| Object storage (S3/GCS) GET first byte | ~20-100 ms | Per-request latency dominates small files. |
| Cross-region network round trip | ~50-150 ms | Why you replicate instead of reading across regions. |
The one that surprises people: an S3 GET has tens of milliseconds of overhead per request. A million tiny files is a million of those. This is the whole argument for compaction.
Throughput anchors
| Resource | Practical throughput | Notes |
|---|---|---|
| Sequential read, single SSD/NVMe | ~1-5 GB/s | A single node can scan a lot before the network is the limit. |
| 10 Gbps NIC | ~1.25 GB/s | The usual per-node network ceiling. |
| One Kafka partition (producer) | tens of MB/s (plan at ~10 MB/s) | Well-tuned setups reach 50-100+ MB/s, but plan conservatively for headroom. |
| One Kafka partition (consumer) | application-bound | The broker is rarely the bottleneck; your processing logic is. |
| Postgres, single primary, OLTP writes | ~thousands-10k rows/s | Order of magnitude; depends heavily on row size and indexes. |
Partition math you will actually use: required-throughput / per-partition-throughput = partition count. Need 300 MB/s and plan a partition at 10 MB/s? ~30 partitions, then round up for growth and skew. Hyperscale shops (Netflix Keystone) plan at an even more conservative 0.5-1 MB/s per partition to leave room for bursts and replication.
File and row-group sizing (Parquet)
| Thing | Target | Why |
|---|---|---|
| Target file size | 128 MB - 1 GB | Small files kill scan performance and metadata. |
| Row group size | 128 MB (default) - 512 MB | The unit of parallelism and predicate pushdown. |
| Page size | ~1 MB | The unit of encoding and compression. |
| Columnar compression ratio | ~3-8x (Zstd on typical data) | How raw event bytes shrink at rest. |
The "small files problem" is the single most common lakehouse pathology. If a table is millions of sub-MB files, column statistics are too coarse to skip anything and every query pays per-file overhead.
Cost anchors (cloud, order of magnitude)
Prices change and vary by region. Carry the magnitudes, not the decimals.
| Item | Rough cost | Implication |
|---|---|---|
| Object storage (S3 Standard) | ~$0.023 / GB-month | 1 TB is ~$23/mo. Storage is cheap. |
| S3 PUT / POST / LIST | ~$0.005 / 1,000 | Writing millions of small files is a real line item. |
| S3 GET | ~$0.0004 / 1,000 | Requests dominate cost for many-small-file access. |
| Cross-AZ data transfer | ~$0.01 / GB each way | Shuffles and cross-AZ replication add up fast. |
| Egress to internet | ~$0.09 / GB | Why you compute next to the data, not across the WAN. |
The lesson interviewers want: requests and data movement, not storage, are what you optimize. Storing 10 TB is trivial; scanning it wrong, or shuffling it across AZs, is the bill.
Streaming and warehouse defaults
| Default | Value | Note |
|---|---|---|
| Kafka max message size | ~1 MB | Above this you store a pointer, not the payload. |
| Kafka default retention | ~7 days | A replay/backfill window, not a system of record. |
| Reasonable freshness for "real-time" analytics | seconds to a few minutes | True sub-second serving is a different, costlier system. |
| Watermark / late-data allowance | minutes to hours | The tradeoff between completeness and latency. |
Estimation shortcuts
The arithmetic that turns "we get a lot of events" into a defensible design.
- Seconds in a day: ~86,400 (round to 100k). 1 million events/day is ~12/s average. 1 billion/day is ~12,000/s average.
- Peak is not average. Multiply average by 3-10x for daily peaks, more for spiky consumer traffic. Design for peak.
- Bytes from counts. A slim event is ~200 B-2 KB. 1 billion events/day at 1 KB is ~1 TB/day raw, before compression pulls it to ~150-300 GB at rest.
- Common field sizes: UUID 16 B, timestamp 8 B, int 4-8 B, a typical JSON event 200 B-2 KB.
- Reads vs writes. Most analytics systems are write-few-read-many at query time but ingest-heavy at write time. State which side you are optimizing.
Every one of these numbers exists to answer one interview question: "how big does this have to be, and where does it hurt first?" You are not memorizing trivia. You are building the reflex to turn a vague volume into a partition count, a file size, and a cost sentence, in that order.
Want the method that puts these numbers to work? Start with the design framework and back-of-the-envelope for data, then work any problem in the catalog.