Compose & Multi-Container Development

The plain-language idea

Docker Compose describes a multi-container application declaratively, in one docker-compose.yml (or compose.yaml) file — every service, its image or build context, its ports, its environment variables, and how services depend on each other. docker compose up reads that file and starts the whole system with one command, instead of a sequence of manually-ordered docker run invocations with matching flags typed by hand every time.

services:
  web:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - api
    environment:
      - API_URL=http://api:4000

  api:
    build: ./api
    ports:
      - "4000:4000"
    environment:
      - DATABASE_URL=postgres://db:5432/app
    depends_on:
      - db

  db:
    image: postgres:16
    environment:
      - POSTGRES_PASSWORD=devpassword
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

See it in a real thing: service names ARE hostnames

Three services declared in one Compose file: web, api, db.

BackNext

Notice API_URL=http://api:4000 — not localhost:4000, and not an IP address. Compose creates a private network for the whole project by default, and every service is reachable from every other service by its service name as a DNS hostname. web reaches api by literally requesting http://api:4000, because Compose's built-in DNS resolves the name api to that container's address on the shared network — no manual network configuration required.

What people usually miss

Watch out

• depends_on controls start order, not readiness. It waits for a dependency's container to start, not for the service inside it to actually be ready to accept connections — a database container can be "started" while Postgres is still initializing. A real system adds an actual readiness check (a healthcheck, or retry logic in the dependent service) rather than trusting depends_on alone to mean "ready."
• Named volumes (like db-data above) persist across docker compose down, but docker compose down -v deletes them — a genuinely destructive flag that's easy to run out of habit and only notice after the database is empty.
• Compose is explicitly a development and small-deployment tool, not a production orchestrator. It doesn't handle multi-host scheduling, automatic failover, or rolling deploys across a cluster — that's what the orchestration lesson later in this track (Kubernetes, ECS) actually exists to solve.
• Environment-specific overrides don't require duplicating the whole file. docker-compose.override.yml (loaded automatically alongside the base file) or multiple -f flags let a team keep one shared base configuration and layer environment-specific differences (a debug port, a bind-mounted source folder for hot reload) on top.

Why this matters in interviews

"How do your frontend and backend containers actually find each other in local dev?" tests whether a candidate understands Compose's networking model or is just pattern-matching a YAML file they've copied before. The specific, correct answer — service names resolve as hostnames on Compose's private network — is a concrete, checkable fact, not a vibe.