Capstone: Project Architecture

Decomposing the Application

A capstone starts with a diagram, not YAML. Take a typical web app and split it into pieces that can fail and scale independently: a web frontend (nginx serving static assets), an API (your language runtime), a background worker consuming jobs, PostgreSQL for state, and Redis for cache or queues.

For every edge, write two contracts: the protocol (HTTP across the compose network, TCP on 5432 for Postgres) and who owns the data. Services must be stateless — persist to Postgres or Redis, never to the container filesystem, or a restarted container loses work. Put everything on one user-defined network so Compose DNS resolves api and db by name instead of hardcoded IPs that change on every up.

Compose Service Topology

services:
  web:
    image: nginx:1.27
    ports: ["8080:80"]
    depends_on:
      api: { condition: service_healthy }
  api:
    build: ./api
    environment:
      DATABASE_URL: postgres://app:secret@db:5432/app
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 10s
  worker:
    build: ./worker
    environment: { REDIS_URL: redis://cache:6379 }
  db:
    image: postgres:16
    volumes: [dbdata:/var/lib/postgresql/data]
volumes:
  dbdata: {}

Only web publishes a host port; db stays reachable solely on the internal network. The named volume dbdata preserves Postgres data across docker compose down, and service_healthy gates startup until the API health check passes.

Architecture Review and Tradeoffs

Run the design through this checklist: does any service write to its own container layer (it should not)? Does scaling the API require redeploying the worker? Is Postgres accidentally published on the host? Each right answer is a boundary you defended.

Common pitfalls: bundling cron into the app container, which couples their lifecycles; using legacy links: instead of default DNS networking; hardcoding container IPs; and embedding database credentials in the image rather than environment or files.

Remember Compose is single-host. The moment you need multi-host scheduling, the same service definitions carry to Swarm or Kubernetes — that portability is part of the architecture's value.

Interview: justify every service with an independent scaling or failure-domain reason, or merge it.