Infrastructure Case Studies
Worked designs, staged on purpose. The first topology in every one is the simplest thing that meets the requirement, and every later stage names the concrete problem that forced it to exist. A stage that cannot name its incident, its ticket or its bill does not belong.
A company marketing site: a dozen pages of HTML, a stylesheet, a JavaScript bundle for the nav, and a few hundred images. Built by a static site generator, published from a git repository, read by a few thousand people a day with a spike whenever the company is mentioned somewhere. This case study exists to teach restraint. It is the shortest design in the set, it has no servers in it at all, and its most important sentence is the last one: anything else you add here makes it worse.
An authenticated JSON API backing a mobile app: accounts, a handful of resources, reads and writes against relational data. A few hundred users at the start, a few tens of requests per second, one small engineering team. This is the most common shape of production system in the world, and it is the design every other case study in this set departs from. Every stage after the first exists because of a specific incident — not because a diagram looked incomplete.
A B2B SaaS product: a browser application, a JSON API used by both the browser and customer integrations, and a few hundred tenant organizations whose usage is wildly uneven — three customers generate more load than the other four hundred combined. Traffic follows European office hours almost perfectly. This design starts as cs-api-database with a CDN in front of it, and every component after that was added by a specific, dated problem.
A data ingestion pipeline: customers submit files of records, each record is validated, enriched against two third-party APIs, and written to a database and to object storage. Volume is spiky and customer-driven — nothing for six hours, then forty thousand records in ten minutes because someone finished an onboarding. This case study is about the operational properties of asynchronous work: how it scales, how it retries, what it does with a job that can never succeed, what identity it runs as, and how you answer "where is my file?".
Users upload video; the platform produces several playback renditions and serves them worldwide. Structurally this is cs-worker-pipeline with much larger payloads and much more expensive work — and that changes the design in ways the smaller pipeline never had to consider. The workers are the entire bill. Every architectural decision here is really a cost decision wearing an engineering costume, and treating it as anything else is how a video product becomes unprofitable at exactly the moment it becomes popular.
A product where customers give an assistant a task and it works on it: calling a model repeatedly, invoking tools, reading the customer's own documents, and producing a result minutes later. From an infrastructure standpoint this is a worker pipeline whose jobs are long, expensive, non-deterministic and hold credentials to systems that cost money — which makes it the worker pipeline with the sharpest edges. The agent behaviour itself belongs to the Agentic Engineering domain; what follows is how you *run* one in production.