Show HN: An atlas of system designs with interactive architecture diagrams

# System Design Atlas Source: [https://atlas-sysdes.vercel.app/](https://atlas-sysdes.vercel.app/) ## Designs 15 Worked problems, ranked by how often they come up\. The first five cover most of what gets asked\. [01### Twitter / Instagram Feed A home timeline serving 150k reads per second, where one post can reach a hundred million followers\. The celebrity problem\. A design that only works for the median user fails — fan\-out cost is bimodal and the code path has to split\. Fan\-outDelivering one event to many recipients, like a post to every follower\.CachingKeeping hot data in fast storage to skip slow lookups\.CassandraWide\-column database built for heavy writes across many nodes\.Core featuresVery fast writes \(LSM tree\)Masterless, no single point of failureLinear scaling by adding nodesTunable consistency per queryMulti\-datacenter replicationWhen to useWrite\-heavy time series and activity feedsAlways\-on, multi\-region dataAccess patterns known upfront by keyPaginationReturning large result sets one page at a time\.](https://atlas-sysdes.vercel.app/docs/01-twitter-instagram-feed)[02### Chat / Slack Fifty million concurrent sockets, ordered message delivery, and users who go offline mid\-conversation\. You have fifty stateful gateway nodes and a message for Alice\. How does the sender find the node holding her socket, and what happens when she's offline? Real\-timePushing updates to clients the moment they happen\.WebSocketsPersistent two\-way connection between browser and server\.Core featuresFull\-duplex over one TCP connectionServer push, no pollingLow per\-message overheadStateful: sticky, harder to load\-balanceWhen to useChat, live collaboration, multiplayerLive feeds, presence, notificationsServer must push without being askedCassandraWide\-column database built for heavy writes across many nodes\.Core featuresVery fast writes \(LSM tree\)Masterless, no single point of failureLinear scaling by adding nodesTunable consistency per queryMulti\-datacenter replicationWhen to useWrite\-heavy time series and activity feedsAlways\-on, multi\-region dataAccess patterns known upfront by keyIdempotencyRepeating a request has the same effect as doing it once\.](https://atlas-sysdes.vercel.app/docs/02-chat-slack)[03### URL Shortener A hundred million links a day and a hundred to one read skew\. The classic estimation warm\-up\. Generating short, unique, non\-guessable keys without a central bottleneck — and recognising this is a cache problem, not a database problem\. EstimationBack\-of\-the\-envelope math for traffic, storage and capacity\.CachingKeeping hot data in fast storage to skip slow lookups\.RedisIn\-memory data store used for caches, counters, queues and pub/sub\.Core featuresSub\-millisecond reads and writesRich types: sorted sets, hashes, streamsTTL expiry per keyAtomic ops and Lua scriptsOptional persistence and replicasWhen to useCaching hot reads in front of a databaseCounters, rate limits, leaderboardsSessions and short\-lived data with TTLShardingSplitting data across machines so no single node holds it all\.](https://atlas-sysdes.vercel.app/docs/03-url-shortener)[04### Distributed Rate Limiter One global limit enforced across a fleet of stateless API servers, at a million requests per second\. Enforcing a global limit without a synchronous Redis round trip on every request — and deciding what happens when the limiter's own store is down\. Rate limitingCapping how many requests a client can make per time window\.RedisIn\-memory data store used for caches, counters, queues and pub/sub\.Core featuresSub\-millisecond reads and writesRich types: sorted sets, hashes, streamsTTL expiry per keyAtomic ops and Lua scriptsOptional persistence and replicasWhen to useCaching hot reads in front of a databaseCounters, rate limits, leaderboardsSessions and short\-lived data with TTLConcurrencyKeeping data correct when many requests touch it at once\.ReliabilityStaying up and correct when parts of the system fail\.](https://atlas-sysdes.vercel.app/docs/04-rate-limiter)[05### Notification System Events from many producers, matched to recipients, delivered in\-app, by email and by push, without losing any\. Third\-party delivery channels fail constantly and are rate limited\. Nothing may be lost, nothing visibly duplicated, and one flaky provider must not take down the rest\. Event\-drivenServices react to published events instead of calling each other\.KafkaDistributed, partitioned commit log for streaming events between services\.Core featuresReplayability: consumers rewind offsetsDurable, replicated partitionsFault tolerant: leader failoverHigh throughput, scales by partitionsOrdering within a partitionWhen to useStreaming events between many servicesReplaying history to rebuild or backfillHigh\-volume logs, metrics, clickstreamsFan\-outDelivering one event to many recipients, like a post to every follower\.IdempotencyRepeating a request has the same effect as doing it once\.Circuit breakerStop calling a failing dependency until it recovers\.](https://atlas-sysdes.vercel.app/docs/05-notification-system)[06### Search and Typeahead A billion documents, a hundred thousand queries a second, and autocomplete firing on every keystroke\. Search is a scatter\-gather, so your latency is your slowest shard\. And the index is not the source of truth — you have to explain how it stays in sync and that it lags\. SearchFinding documents by text, usually through an inverted index\.ElasticsearchDistributed search engine built on inverted indexes\.Core featuresFull\-text search with relevance rankingNear real\-time indexingSharded and replicatedAggregations and facetingFuzzy matching and autocompleteWhen to useFull\-text search and typeaheadSearching and analyzing logsFiltering and faceting across many fieldsShardingSplitting data across machines so no single node holds it all\.CachingKeeping hot data in fast storage to skip slow lookups\.](https://atlas-sysdes.vercel.app/docs/06-search-typeahead)[07### Uber / Delivery Tracking Five million drivers publishing position every four seconds, matched to riders in real time\. Two problems glued together: 1\.25M location writes per second that destroy any disk\-backed index, and a matching step where two riders must never get the same driver\. GeospatialIndexing and querying things by location on a map\.RedisIn\-memory data store used for caches, counters, queues and pub/sub\.Core featuresSub\-millisecond reads and writesRich types: sorted sets, hashes, streamsTTL expiry per keyAtomic ops and Lua scriptsOptional persistence and replicasWhen to useCaching hot reads in front of a databaseCounters, rate limits, leaderboardsSessions and short\-lived data with TTLConcurrencyKeeping data correct when many requests touch it at once\.Real\-timePushing updates to clients the moment they happen\.SagaA multi\-step transaction undone by compensating steps on failure\.](https://atlas-sysdes.vercel.app/docs/07-uber-delivery-tracking)[08### Video Streaming Upload, transcode and deliver video at twenty\-five terabits per second of egress\. Video bytes never touch your application servers — not on upload, not on playback\. What you actually build is a metadata service and a transcoding pipeline\. Object storageCheap, durable storage for files and blobs, like S3\.Core featuresExtreme durability \(11 nines\)Virtually unlimited scaleLow cost per GB, storage tiersPresigned URLs for direct uploadsWhole\-object writes, no in\-place editsWhen to useUser uploads, media and backupsLarge files rather than queryable recordsData lakes and long\-term archivesCDNEdge servers that serve content from close to the user\.Core featuresLow latency from nearby edgesOffloads traffic from the originCaches static files and mediaAbsorbs traffic spikes and DDoSWhen to useStatic assets, images and videoUsers spread far from your originCacheable API responses at the edgeChunkingSplitting large files into pieces to upload, dedupe and sync\.Stream processingComputing results continuously over unbounded event streams\.](https://atlas-sysdes.vercel.app/docs/08-video-streaming)[09### Web Crawler Ten billion pages, ten thousand fetches a second, without hammering any single domain\. Politeness\. Crawling fast is easy; crawling fast without overloading one host forces a queue design grouped by host rather than FIFO\. Then dedupe at a scale where you can't store what you've seen\. Bloom filterCompact set check that answers 'definitely not' or 'probably yes'\.DeduplicationDetecting and dropping repeated items or messages\.Consistent hashingMapping keys to nodes so adding a node moves few keys\.Rate limitingCapping how many requests a client can make per time window\.](https://atlas-sysdes.vercel.app/docs/09-web-crawler)[10### Payment System Charges, captures, refunds and payouts across an unreliable external processor, with a ledger that has to balance\. The one design where consistency beats availability, and where at\-least\-once plus idempotent stops being a slogan and becomes the mechanism preventing double charges\. ConsistencyWhether every reader sees the latest write, and how soon\.IdempotencyRepeating a request has the same effect as doing it once\.SagaA multi\-step transaction undone by compensating steps on failure\.OutboxWrite the event to the database with the data, then publish it\.PostgresRelational SQL database, the safe default for transactional data\.Core featuresACID transactionsJoins, constraints, foreign keysStrong consistencyExtensions: JSONB, PostGIS, full\-textRead replicas via streaming replicationWhen to useMoney, orders, anything needing transactionsRelational data queried with joinsThe default until scale forces otherwise](https://atlas-sysdes.vercel.app/docs/10-payment-system)[11### Ticketmaster / Booking Fifty thousand people wanting the same hundred seats in the same second\. This is contention, not scale\. Row lock contention breaks first, not throughput — so the answer is admission control in front of the application tier, not a bigger cluster\. ConcurrencyKeeping data correct when many requests touch it at once\.ConsistencyWhether every reader sees the latest write, and how soon\.PostgresRelational SQL database, the safe default for transactional data\.Core featuresACID transactionsJoins, constraints, foreign keysStrong consistencyExtensions: JSONB, PostGIS, full\-textRead replicas via streaming replicationWhen to useMoney, orders, anything needing transactionsRelational data queried with joinsThe default until scale forces otherwiseSagaA multi\-step transaction undone by compensating steps on failure\.](https://atlas-sysdes.vercel.app/docs/11-ticketmaster-booking)[12### Dropbox / File Sync Syncing files across devices without re\-uploading a two gigabyte file because one paragraph changed\. Bandwidth efficiency through content\-defined chunking and delta sync — plus a coherent story for two clients that edited the same file offline\. ChunkingSplitting large files into pieces to upload, dedupe and sync\.DeduplicationDetecting and dropping repeated items or messages\.Object storageCheap, durable storage for files and blobs, like S3\.Core featuresExtreme durability \(11 nines\)Virtually unlimited scaleLow cost per GB, storage tiersPresigned URLs for direct uploadsWhole\-object writes, no in\-place editsWhen to useUser uploads, media and backupsLarge files rather than queryable recordsData lakes and long\-term archivesConsistencyWhether every reader sees the latest write, and how soon\.](https://atlas-sysdes.vercel.app/docs/12-dropbox-file-sync)[13### Ad Click Aggregation A million events a second aggregated into dashboards that are fast and billing numbers that are exact\. Event time\. Clicks arrive late, out of order and duplicated\. Aggregating by arrival time is easy and wrong, and advertisers are billed from these numbers\. Stream processingComputing results continuously over unbounded event streams\.FlinkStream processor for stateful, real\-time computations\.Core featuresExactly\-once state via checkpointsEvent\-time windows and watermarksLow\-latency processingLarge keyed state, fault tolerantWhen to useReal\-time aggregates and alertsFraud or anomaly detection on streamsJoining and windowing event streamsOLAPAnalytical databases tuned for aggregating huge datasets\.Core featuresColumnar storage and compressionFast aggregates over billions of rowsMaterialized views and rollupse\.g\. ClickHouse, Druid, BigQueryWhen to useDashboards over huge event tablesAd\-hoc analytical queriesAggregations rather than per\-row updatesKafkaDistributed, partitioned commit log for streaming events between services\.Core featuresReplayability: consumers rewind offsetsDurable, replicated partitionsFault tolerant: leader failoverHigh throughput, scales by partitionsOrdering within a partitionWhen to useStreaming events between many servicesReplaying history to rebuild or backfillHigh\-volume logs, metrics, clickstreamsDeduplicationDetecting and dropping repeated items or messages\.](https://atlas-sysdes.vercel.app/docs/13-ad-click-aggregation)[14### Distributed Cache Building Redis: a hundred nodes holding a terabyte of hot data with sub\-millisecond reads\. Rebalancing\. Naive modulo hashing invalidates eighty percent of the cache when you add a node and stampedes the origin\. And consistent hashing does not solve hot keys\. Consistent hashingMapping keys to nodes so adding a node moves few keys\.CachingKeeping hot data in fast storage to skip slow lookups\.RedisIn\-memory data store used for caches, counters, queues and pub/sub\.Core featuresSub\-millisecond reads and writesRich types: sorted sets, hashes, streamsTTL expiry per keyAtomic ops and Lua scriptsOptional persistence and replicasWhen to useCaching hot reads in front of a databaseCounters, rate limits, leaderboardsSessions and short\-lived data with TTLReplicationKeeping copies of data on several nodes for durability and read scale\.](https://atlas-sysdes.vercel.app/docs/14-distributed-cache)[15### Google Docs Many people typing into one document at once, with no perceptible lag and no lost edits\. Convergence\. Two users edit the same sentence with no coordination\. Both must end up with an identical document and neither edit may be silently lost — so last\-write\-wins is catastrophically wrong\. CRDT / OTMerging concurrent edits so every copy converges to the same state\.ConsistencyWhether every reader sees the latest write, and how soon\.WebSocketsPersistent two\-way connection between browser and server\.Core featuresFull\-duplex over one TCP connectionServer push, no pollingLow per\-message overheadStateful: sticky, harder to load\-balanceWhen to useChat, live collaboration, multiplayerLive feeds, presence, notificationsServer must push without being askedReal\-timePushing updates to clients the moment they happen\.](https://atlas-sysdes.vercel.app/docs/15-google-docs-collaborative-editing)