How many users are we designing for-and are they mostly reading, writing, or both?
Gather begins as a small event app. As its audience grows, production problems appear: a launch creates a traffic spike, two requests race for the last seat, reminders fall behind, a database slows down, and an outage tests the team's recovery plan.
Instead of choosing fashionable architecture by reflex, the team asks what users need, measures where the current constraint lives, and tries a change it can test.
Follow the app from a developer's laptop through production. Learn to reason about:
Read-heavy and write-heavy workloads, traffic estimates, and capacity targetsVertical and horizontal scaling, caching, replication, partitioning, and shardingMonoliths, microservices, and the useful designs between themDatabases, indexes, transactions, idempotency, concurrency, batching, and async writesQueues, worker pools, transactional outboxes, workflows, retries, backoff, and circuit breakersWebSockets, long polling, server-sent events, webhooks, proxies, load balancers, and CDNsDocker, Compose, Linux, Kubernetes, Git, CI/CD, AWS, Azure, Redis, RabbitMQ, S3, R2, and NGINXLogging, monitoring, incidents, backups, and restore drillsEach chapter follows the Gather team as new users, support tickets, failures, and operational pressure reveal the next design decision. Pause for practical questions before you read the worked answers at the back. Print-friendly references let you find each answer after making your own call.
There is rarely one universally correct architecture. The goal is to understand the trade-offs, gather evidence, and choose a design that fits today's users and can change as their needs grow.