System design templates, drawn by the engine.

Every diagram below was produced by the layout engine that ships in the app, from a semantic graph rather than hand-placed boxes. Each page lists the components, the design decisions behind them and what those decisions cost.

• URL Shortener System Design
  The canonical read-heavy system: roughly a hundred reads for every write, and a redirect that has to be fast enough that nobody notices it happened.
• Chat Application System Design
  Long-lived connections change everything: the hard part is not storing messages, it is knowing which of your servers is holding the socket you need to write to.
• Payment System Design
  The only system on this list where being approximately right is indistinguishable from being wrong, and where the provider, not you, holds the truth.
• RAG Pipeline Architecture
  Almost every RAG system that disappoints is failing at retrieval, not generation, and the architecture is what decides whether you can tell.
• E-commerce Platform Architecture
  Four services with four completely different consistency requirements, which is the whole reason this is not one application.
• Notification Service Design
  The architecture is straightforward. The reason this needs to be one service is that the rules about when not to send are the hard part, and they have to live somewhere every sender passes through.
• Distributed Rate Limiter Design
  Every design here is a trade between how accurate the limit is and how much latency you are willing to add to every single request to achieve it.
• Observability Stack Architecture
  The architecture is mostly about cost control. Collecting everything is technically easy and financially ruinous, so the interesting decisions are all about what to throw away.
• Authentication Service Design
  Stateless tokens make verification free and revocation hard, and that single tradeoff explains most of the components in this diagram.
• Event-Driven Microservices Design
  Distributed transactions do not exist here, so every consistency guarantee you want has to be rebuilt out of events, retries and compensation.
• LLM Inference Service Design
  GPUs are the budget, so almost every decision here is about keeping them busy without letting the queue destroy tail latency.
• CI/CD Pipeline Architecture
  Two things decide whether people trust a pipeline: how fast it is, and whether a red build actually means something is broken.
• Ride Sharing System Design
  Every driver streams their position every few seconds whether or not anyone is riding, which makes this one of the few consumer systems where writes dominate reads.
• Video Streaming System Design
  Around ninety-nine percent of the bytes never touch your servers, which means most of this design is about preparing files so the CDN can do the work.
• Social Media Feed System Design
  Fan-out on write is the right answer until someone with ten million followers posts, and the entire design exists to handle that exception.
• Web Crawler System Design
  The engineering problem is not fetching pages quickly. It is fetching them politely, at scale, without visiting the same content a thousand times.
• Search Autocomplete System Design
  This is a latency problem wearing a search problem's clothes: past about a hundred milliseconds users have already typed the next character and your response is worthless.
• File Storage Service Design
  The design goal is to keep file bytes away from your servers entirely, so that what you run is a metadata service that happens to be about files.
• Ticket Booking System Design
  A named seat can be sold exactly once, and ten thousand people want it at the same instant. Everything here follows from that.
• Food Delivery System Design
  Three sides to coordinate and one deadline that nobody controls: the kitchen. Dispatch quality matters more here than any amount of throughput.
• Multiplayer Game Backend Design
  Latency is the product. Every architectural decision here is subordinate to keeping the round trip between a player and the simulation short.
• Multi-Tenant SaaS Architecture
  One database serving every customer, and exactly one bug standing between that and showing one customer another customer's data.
• Data Warehouse ETL Pipeline Design
  Land the raw data first and transform it later, because the transformation you want in six months is not the one you would write today.
• IoT Telemetry Platform Design
  Assume every device is offline, on a bad network, running firmware from two years ago, and cannot be recalled. The architecture follows from that.