5. Choose the smallest production shape

Production architecture is a response to requirements. Start with the smallest shape that meets them, then add machinery when evidence makes the next problem real.

Ask about the system before the platform

  1. Traffic. What is the expected request rate, and is it steady or bursty?
  2. Availability. How much downtime is acceptable, and what does failure cost?
  3. Data. What must persist, how quickly must it recover, and where may it legally live?
  4. Release frequency. How often will the application change, and how quickly must it roll back?
  5. Team capacity. Who receives the alert, performs upgrades, and understands the platform at 3am?
  6. Constraints. Are there compliance, networking, portability, or cost limits?

Only then choose the platform. A managed application platform is often the right first answer because it gives a small team HTTPS, deployments, logs, restarts, and simple scaling without turning infrastructure into the product. A virtual machine buys control at the cost of patching and supervision. Managed containers preserve a portable image while outsourcing much of the cluster. Kubernetes becomes a candidate when its control-plane capabilities match problems the organisation actually has.

A production minimum

Small does not mean careless. Even the simplest live service needs a clear release, external HTTPS, configuration kept out of source control, persistent data with tested backups, health checks, useful logs, basic monitoring, and a rollback path. The platform can supply many of those pieces, but you still own the decisions and verification.

A small production architecture 
smallest dependable shape

managed app service ─── application process or container
          │
          ├── managed database
          ├── secret/configuration store
          ├── logs + health checks + alerts
          └── automated deploy with rollback

Apply the map

Imagine a paid reading app with a mobile client and a Python API. It has a few thousand users, offline reading, purchase entitlements, and reading-position sync. A defensible first production shape is a managed container service for the API, a managed PostgreSQL database, object storage for book assets, and a CI/CD pipeline that deploys an immutable image after tests pass.

Docker packages the API. The platform runs it. PostgreSQL remains the source of truth for accounts, purchases, and progress. Object storage serves large files. Monitoring watches latency, errors, and failed sync requests. Kubernetes adds no necessary capability at this scale, so it stays outside the architecture.

Final checkpoint

A teammate says, "We need Docker, AWS, and Kubernetes." What questions turn that tool list into an architecture decision?

Ask what must be packaged, where it must run, what availability and scale it needs, what data must persist, how releases and rollbacks work, and who operates the result. Docker may answer packaging, AWS may supply several possible hosting services, and Kubernetes may answer multi-workload orchestration. None is justified until its requirement is clear.

What should you read next if you understand the map but have not built it?

Use Chapter 20 for a first managed deployment. Then follow Chapters 27–30 for the complete path through Docker, Compose, AWS, CI/CD, observability, operations, and the production capstone.

Closing

The map is deliberately stable even when tools change. Code must execute. Traffic must find it. Data must persist. Releases must be identifiable and reversible. Failures must become visible. Capacity must meet demand. Every platform is a bundle of answers to those recurring questions.

That is the production skill the book has been building: not collecting infrastructure nouns, but locating a problem, choosing the smallest dependable answer, and proving that the resulting system works.