The 30 second answer
I start with the questions that size everything: what one record is, how fast records arrive, how they are read, how fresh results must be, and how long data is kept. Then I partition by the key the reads use, process in parallel with idempotent, restartable steps, and pick storage per access pattern: a log for movement, a columnar or partitioned store for scans, a search index for discovery. Estimates come from variables, not invented numbers.
Public candidate reviews of Zalando interviews mention "how would you model a problem with billions of records". The question is deliberately open: the interviewer wants to see you drive requirements, estimate, and choose partitioning and storage, not recite a stack.
Clarify before drawing.
- What is a record (a product view event, an offer, a price change) and roughly how large is it?
- How fast do records arrive on average and at peak? Peak matters more during sale events.
- How is the data read: point lookups by key, scans and aggregates over time ranges, or full-text and faceted search?
- How fresh must results be: seconds, minutes, or a nightly batch?
- How long is it kept, and is it ever deleted or corrected?
Estimate with variables. Storage is roughly record count times average record size times replication, plus index overhead. Throughput is peak records per second times processing cost per record. Writing the formula first and plugging in the interviewer's numbers avoids inventing figures, and shows which variable dominates.
Partition by the read key. Every scalable design splits data so work can proceed in parallel and a query touches as few pieces as possible.
- In a log such as Kafka, events with the same key go to the same partition and are read in the order they were written, so key by the entity whose order matters (SKU, customer).
- In PostgreSQL, declarative partitioning by time or key lets queries prune to the relevant partitions, and the docs point out that dropping or detaching a partition is far faster than a bulk delete and avoids the VACUUM overhead.
- In Elasticsearch, primary shards split an index; size them deliberately rather than by default.
Process in parallel, safely. The MapReduce model, map records to key-value pairs and reduce all values for a key, still describes most batch work. For continuous data, a stream processor keyed by entity keeps per-key state (as in the Flink question above). Either way, make steps idempotent and restartable: deterministic outputs keyed by record id, checkpoints, and the ability to replay from the log.
Pick storage per access pattern.
| Need | Typical choice |
|---|---|
| Moving and replaying events | Partitioned log (Kafka, Nakadi) |
| Point lookups by key at scale | Key-value or partitioned relational store |
| Large scans and aggregates | Columnar warehouse or partitioned tables |
| Full-text and faceted discovery | Search index built from the log |
Close with operations. Backfills and reprocessing, data quality checks, hot keys, cost per stored and processed record, and how you would observe lag end to end.
Alternate interview scenarios
"Find the top products by views over the last hour from billions of events."
Key events by product, count in a stream processor with tumbling or sliding windows, and keep a per-partition top list that a final step merges, the same partial-top-then-merge idea Elasticsearch uses for terms aggregations. If exact counts are not required, an approximate sketch reduces memory, and the trade-off should be stated explicitly.
"A full reprocess of all records is needed after a bug fix. How?"
Replay from the retained log, or from snapshots plus the log, into a new output (a new table or index) while the old one keeps serving, then switch with an alias or a view and keep the old output until checks pass. Make the job idempotent so it can be restarted from checkpoints without double counting.
Sources (4)
- PostgreSQL: Table partitioningpostgresql.org
- Apache Kafka: Introduction (partitions and ordering)kafka.apache.org
- Dean and Ghemawat, MapReduce: Simplified Data Processing on Large Clusters (Google Research)research.google
- Elasticsearch: Size your shardselastic.co