Architecture Case Studies — Series 2

Preview — 3 of 10 questions

Design the core matching mechanism for a ride-sharing app: given a riders location, find nearby available drivers quickly among potentially millions of drivers whose GPS positions update every few seconds. Whats a standard approach?

ACompare the rider's coordinates against every single driver's coordinates on every match request, computing exact distance for each one (a full O(n) scan across all drivers)

BStore driver locations sorted by latitude only, and use binary search to find the answer, since longitude has no impact on physical proximity

CUse a geospatial index (like a geohash grid or quad-tree) that groups drivers into spatial "cells" — a match request only needs to query the handful of cells near the rider's location (and expand outward if too few drivers are found), turning an expensive full scan into a fast, indexed lookup over a small, localized subset of drivers, with driver location updates simply moving a driver from one cell to another as they move

DRequire every driver to broadcast their location to every other driver directly, with no central server involved in matching at all

Design the high-level architecture for a service like Dropbox: users upload files that sync across their devices and can be shared with others. What are the core building blocks, and why is chunking large files into smaller pieces useful?

AThe entire file must always be re-uploaded from scratch on every single sync, regardless of how small the actual change was, since chunking provides no benefit for sync efficiency

BA single relational database table is sufficient to store the complete binary content of every file, with no separate object storage layer needed

CChunking exists purely to make files harder to read directly and has no relationship to sync efficiency or storage optimization

DCore components typically include: object storage for the actual file bytes (often chunked into fixed-size blocks rather than stored as one giant blob), a metadata database tracking file/folder structure, ownership, and version history, and a sync/notification mechanism that tells other devices when something's changed. Chunking large files into smaller pieces is useful because it means only the changed chunks of a modified file need to be re-uploaded/re-downloaded on a sync (rather than the entire file), and identical chunks across different files or versions can potentially be deduplicated, saving both bandwidth and storage

Design the core data model for a payment processing system that must never lose track of money and must be safe against duplicate charge attempts (e.g., from a client retrying a failed request). What two techniques are foundational here?

AStoring only a single running balance per account, updated in place with each transaction, with no historical transaction log kept at all

BDouble-entry bookkeeping (every transaction records two balanced entries — a debit to one account and a matching credit to another, so the books always sum to zero and every movement of money is traceable) combined with idempotency keys (a unique identifier attached to each payment request, checked before processing, so if the same request is retried — due to a network error or client retry logic — it's recognized as a duplicate and not applied a second time). Together, these ensure the ledger stays both an accurate historical record and resistant to double-charging from retries

CIdempotency is achieved by never allowing any payment request to be retried under any circumstances, even after a legitimate network failure

DDouble-entry bookkeeping means recording each transaction exactly once, in a single account, with no corresponding second entry anywhere

Answer all 10 questions (7 more), see explanations for every answer, and track your score.