Compose, Networking and Persistent Data

MODULE 19 · LESSON 19.2

Run multiple services with health-aware dependencies and persistent database storage.

Practice-firstBeginner-friendlyProduction-aware

Where this fits in CourseFlow

This topic earns its place in CourseFlow by changing something another person can inspect, test or review. This lesson controls how a working change survives machines, environments, traffic and failure after it leaves a developer laptop.

Here, that decision supports a specific checkpoint: Containerize the API and PostgreSQL development stack. A reviewable result should include a command transcript, CI result, deployment check and rollback note rather than a claim that the feature simply works.

Compose, Networking and Persistent Data workflowA four-step visual showing Compose services, service DNS, volumes, health checks.Compose, Networking and Persistent Data workflow1Compose Services2Service DNS3Volumes4Health Checks

Compose, Networking and Persistent Data workflow

  1. 1Compose Services
  2. 2Service DNS
  3. 3Volumes
  4. 4Health Checks
Compose, Networking and Persistent Data workflow: a practical sequence used in this lesson.

A practical model for compose, networking and persistent data

Run multiple services with health-aware dependencies and persistent database storage. The useful unit of understanding is the boundary: who owns the decision, which input crosses it, what result is visible and how a failure is reported.

  • Compose Services: Name its input, observable result and most likely failure in this lesson.
  • Service DNS: Locate this responsibility in CourseFlow and defend the boundary you chose.
  • Volumes: Implement one behavior that another learner can reproduce without reading your mind.
  • Health Checks: Compare the simplest correct approach with one credible alternative.

Read the result, not just the syntax

Start by locating Compose services in the sample. Then trace what reaches service DNS and what the caller receives back.

YAML
services:
  db:
    image: postgres:18
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app"]
  api:
    build: .
    depends_on:
      db:
        condition: service_healthy
Make one assumption explicit

Write down what the sample assumes about Compose services. Break that assumption deliberately and inspect the response.

Build the smallest useful version

  1. 1
    Compose Services

    Break one assumption on purpose, make recovery clear and record the trade-off you accepted.

  2. 2
    Service DNS

    Name the caller and the owner of this behavior before changing the implementation.

  3. 3
    Volumes

    Compare expected and actual output before editing; the difference tells you where to investigate.

  4. 4
    Health Checks

    Keep names tied to the product rule so a reviewer can follow the change without decoding abbreviations.

Failure patterns to recognize

  • Treating Compose services as vocabulary instead of defining the behavior it must produce.
  • Testing the expected path while ignoring an empty, invalid, repeated or unauthorized case around service DNS.
  • Allowing volumes to cross a boundary without an explicit contract or useful error.
  • Changing several layers before capturing the first piece of evidence, which makes the original cause harder to see.

A debugging route that preserves evidence

  1. Reduce the problem to the smallest failing Compose, Networking and Persistent Data case.
  2. Capture the actual input and output at the Compose services boundary.
  3. Read the first relevant error, request, trace or query rather than the loudest downstream symptom.
  4. Test one explanation for the failure in service DNS; avoid changing two variables together.
  5. Keep a regression check that would expose the same defect if it returned.

Security decision

Use least privilege, protected secrets, reviewed dependencies and reversible changes. A deployment shortcut must never weaken the application boundary.

Performance decision

Establish a baseline, observe resource use and latency, and keep a rollback signal. Capacity changes without measurement are guesses.

PRACTICE

Build something you can inspect

Run API and database together, migrate the schema and prove data survives a container replacement.

Stretch challenge

Add observability for service DNS without leaking personal data, secrets or noisy implementation details.

Definition of done

  • The behavior around Compose services works with realistic input.
  • A failure involving service DNS is handled clearly and without leaking sensitive detail.
  • The implementation remains keyboard-usable when it produces an interface.
  • Your evidence directly supports the claim made in the exercise.
  • The README records the important trade-off without pretending the solution is universal.

Check your reasoning

Why is localhost inside a container not the host machine or another container?

Answer by naming the expected Compose services behavior, the layer responsible for it and the evidence that would confirm your explanation.

Where would you investigate the first failure?

Start where service DNS crosses a boundary. Compare the actual input and output there before following downstream symptoms.

What would make this work reviewable?

Show the focused change, repeatable steps, the result of your check and one honest trade-off connected to volumes.

What to carry into the next lesson

  • Run multiple services with health-aware dependencies and persistent database storage.
  • Keep Compose services visible at the boundary where it can be tested.
  • Use evidence from service DNS before widening the implementation.

References and related reading

Progress is stored only in this browser.

Share this page

Share this page with the people who will use it next.

X Facebook LinkedIn WhatsApp Email

Discussion

No comments yet. Add the first useful question or observation.