Docker Compose Basics

Beginner·2 min read

Fast recall

Quick revision

Core answer

A YAML file describing the multi-container app (app + DB + cache): services, ports, env vars, depends_on, volumes. docker compose up — the whole stack, networked. The local environment that mirrors prod.

Interview Answer2 min

The compose file for a Go service + PostgreSQL:

version: "3.9"
services:
  app:
    build: .                    # build from the Dockerfile
    ports:
      - "8080:8080"            # host:container
    environment:
      DATABASE_URL: postgres://db:5432/app?sslmode=disable
    depends_on:
      db:
        condition: service_healthy
    volumes:
      - ./:/app                 # dev: live-reload the source

  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: app
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:                        # named volume — the DB survives restarts

The commands:

docker compose up -d       # the whole stack, detached
docker compose logs -f app  # the app's output
docker compose down         # stop and remove
docker compose down -v     # also remove volumes (the DB)

The features interviewers probe:

The NETWORK: compose creates a network where services reach each other by NAME (the app connects to db:5432 — the hostname IS the service name)
depends_on + healthcheck: the app waits for the DB to be READY (not just started) — the startup-order problem solved
The named volume (pgdata): the DB's data survives compose down (survives the container); -v deletes it
The dev-mode volume mapping (./:/app): the host's source mounted in the container — Go's live-reload setups run on this

Interview-ready guide

Interview answer

The compose file for a Go service + PostgreSQL:

version: "3.9"
services:
  app:
    build: .                    # build from the Dockerfile
    ports:
      - "8080:8080"            # host:container
    environment:
      DATABASE_URL: postgres://db:5432/app?sslmode=disable
    depends_on:
      db:
        condition: service_healthy
    volumes:
      - ./:/app                 # dev: live-reload the source

  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: app
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:                        # named volume — the DB survives restarts

The commands:

docker compose up -d       # the whole stack, detached
docker compose logs -f app  # the app's output
docker compose down         # stop and remove
docker compose down -v     # also remove volumes (the DB)

The features interviewers probe:

The NETWORK: compose creates a network where services reach each other by NAME (the app connects to db:5432 — the hostname IS the service name)
depends_on + healthcheck: the app waits for the DB to be READY (not just started) — the startup-order problem solved
The named volume (pgdata): the DB's data survives compose down (survives the container); -v deletes it
The dev-mode volume mapping (./:/app): the host's source mounted in the container — Go's live-reload setups run on this

03 · Deep dive

Docker Compose Basics

About 2 min with examples

Direct Answer

Deep Dive & Architecture

The name-resolution mechanics: compose creates a bridge network; each service gets a DNS alias matching its name. The app's DATABASE_URL references db:5432 — the name resolves to the DB container's IP on the compose network. The same pattern in Kubernetes is the Service; in prod, the service discovery — compose is the local mirror.

The depends_on evolution: the simple form (depends_on: [db]) waits for the DB container to START — not for PostgreSQL to be READY to accept connections (the race: app connects to a starting DB, gets a connection refused). The healthcheck form (condition: service_healthy) solves it — the app's start waits until pg_isready succeeds. The production equivalent: readiness probes + init containers.

The volume types: named (pgdata — compose-managed, the data survives) vs bind (./:/app — the host directory mapped in, the dev-time live code). The volume lifecycle: down preserves named volumes; down -v removes — the dev-reset command for the database.

Common Mistakes & Pitfalls

Giving a definition without explaining a practical trade-off.

Check your understanding

Answer these without looking back at the article.

When would you use Docker Compose Basics in a real project?
How would you compare Docker Compose Basics with an alternative?
What is a common mistake when using Docker Compose Basics?

debug a problem involving Environment Variables Docker

Continue · Next question · Q 22/30

When would you use Docker Compose Basics in a real project

Full prep

Looking for a structured roadmap?

Every module on this page is also part of the full Java backend interview track.

Open the full roadmap Browse all prep categories

Previous Next

Docker Compose Basics

Beginner·2 min read

Fast recall

Quick revision

Core answer

Interview Answer2 min

The compose file for a Go service + PostgreSQL:

version: "3.9"
services:
  app:
    build: .                    # build from the Dockerfile
    ports:
      - "8080:8080"            # host:container
    environment:
      DATABASE_URL: postgres://db:5432/app?sslmode=disable
    depends_on:
      db:
        condition: service_healthy
    volumes:
      - ./:/app                 # dev: live-reload the source

  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: app
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:                        # named volume — the DB survives restarts

The commands:

docker compose up -d       # the whole stack, detached
docker compose logs -f app  # the app's output
docker compose down         # stop and remove
docker compose down -v     # also remove volumes (the DB)

The features interviewers probe:

The NETWORK: compose creates a network where services reach each other by NAME (the app connects to db:5432 — the hostname IS the service name)
depends_on + healthcheck: the app waits for the DB to be READY (not just started) — the startup-order problem solved
The named volume (pgdata): the DB's data survives compose down (survives the container); -v deletes it
The dev-mode volume mapping (./:/app): the host's source mounted in the container — Go's live-reload setups run on this

Interview-ready guide

Interview answer

The compose file for a Go service + PostgreSQL:

version: "3.9"
services:
  app:
    build: .                    # build from the Dockerfile
    ports:
      - "8080:8080"            # host:container
    environment:
      DATABASE_URL: postgres://db:5432/app?sslmode=disable
    depends_on:
      db:
        condition: service_healthy
    volumes:
      - ./:/app                 # dev: live-reload the source

  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: app
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:                        # named volume — the DB survives restarts

The commands:

docker compose up -d       # the whole stack, detached
docker compose logs -f app  # the app's output
docker compose down         # stop and remove
docker compose down -v     # also remove volumes (the DB)

The features interviewers probe:

The NETWORK: compose creates a network where services reach each other by NAME (the app connects to db:5432 — the hostname IS the service name)
depends_on + healthcheck: the app waits for the DB to be READY (not just started) — the startup-order problem solved
The named volume (pgdata): the DB's data survives compose down (survives the container); -v deletes it
The dev-mode volume mapping (./:/app): the host's source mounted in the container — Go's live-reload setups run on this

03 · Deep dive

Docker Compose Basics

About 2 min with examples

Direct Answer

Deep Dive & Architecture

Common Mistakes & Pitfalls

Giving a definition without explaining a practical trade-off.

Check your understanding

Answer these without looking back at the article.

When would you use Docker Compose Basics in a real project?
How would you compare Docker Compose Basics with an alternative?
What is a common mistake when using Docker Compose Basics?

debug a problem involving Environment Variables Docker

Continue · Next question · Q 22/30

When would you use Docker Compose Basics in a real project

Full prep

Looking for a structured roadmap?

Every module on this page is also part of the full Java backend interview track.

Open the full roadmap Browse all prep categories