Choosing a store, sharding and partitioning, replication topologies, and storage-engine trade-offs.
8 questions in System Design.
Replication propagates the deletion, so recovery depends on point-in-time restore from a base backup plus the write-ahead log, and the hard part is not the restore but extracting one tenant's rows from a shared store while the rest of the system keeps serving traffic.
A geospatial index for nearby drivers reduces latitude and longitude to ordered cells such as geohash, S2 or H3. Query the rider's cell plus neighbours, keep the hot current-position index in memory because positions churn, and filter candidates by true distance afterwards.
A direct-to-storage upload keeps API servers off the byte path. The API issues short-lived scoped credentials and records a pending row; the client uploads multipart parts to object storage, and a storage event or reconciliation job marks the file ready. It also connects presigned urls to the point an interviewer is testing.
Choose the store from the dominant access pattern and the invariants it must enforce, not from a category label. Choose the shard key so the most frequent query is answerable from one shard, the key has enough distinct high-traffic values to spread load, and shards can be split later without rewriting every row.
Put the equality predicates first in a composite index and the ordering column last, so one index serves the filter, the sort and the limit. Every index is a write tax, and whether that tax is a random in-place page update or a sequential append is the difference between a B-tree engine and an LSM engine.
A hot partition from one account cannot be fixed by ordinary rebalancing because it is one key. Split the key into write-sharded sub-keys or aggregate writes before storage; both choices move cost to reads, ordering, rollups or approximation.
Photo storage should separate originals from thumbnails. Originals are large, rarely read and irreplaceable, so keep a canonical erasure-coded object; thumbnails are small, hot and rebuildable, so replicate them, cache them at the edge and address them by content or transform version.
An uncompromising examination of split-brain resolution, quorum consensus, fencing tokens, and why timestamp-based last-write-wins is fundamentally flawed. Use this distributed systems answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects databases to the point an interviewer is testing.