Stage 7 · Master
Phase 1 — Project Foundation
Redis Setup
Add Redis to compose now, with a password required even in local development, so caching and rate-limiting phases later never have to touch infrastructure again.
What Redis Will (and Will Not) Own Later
No code in this course's scope talks to Redis yet — the organization service, fully built in Phase 2, depends only on PostgreSQL. Redis is provisioned now because later phases (caching, session storage, rate limiting) will need it, and standing it up once, correctly, alongside Postgres means those phases start writing Go code on day one instead of debugging infrastructure. Redis will never be a system of record in this platform: anything it holds must be reconstructable from PostgreSQL or Kafka if it were lost.
Requiring a Password Even in Local Development
It would be simpler to run Redis with no authentication locally and add a password only in production configuration. That approach hides an entire category of configuration bug — code that forgot to pass a password — until the first deployment, which is the worst possible place to discover it. Requiring authentication locally, with an obviously-fake development password, means any code path that fails to send credentials fails immediately, on a contributor's own machine, in a comprehensible way.
volumes:
pg-data:
+ redis-data:
services:
+ redis:
+ image: redis:7-alpine
+ restart: unless-stopped
+ command: ["redis-server", "--requirepass", "hoa_redis_dev_password"]
+ ports:
+ - "6379:6379"
+ volumes:
+ - redis-data:/data
+ healthcheck:
+ test: ["CMD-SHELL", "redis-cli -a hoa_redis_dev_password ping | grep PONG"]
+ interval: 5s
+ timeout: 3s
+ retries: 5
+ networks:
+ - hoa-net
The network, Adminer, and PostgreSQL definitions remain unchanged from the preceding lessons. Showing only Redis's volume and service makes the new authentication and persistence decisions visible.
Verifying Authentication, Not Just Connectivity
A healthcheck or a smoke test that only confirms Redis accepts TCP connections would pass even if authentication were silently misconfigured — the port is open either way. The verification below deliberately runs the unauthenticated command first, expects it to fail with Redis's own NOAUTH error, and only then supplies the password — proving the requirement is actually enforced, not just present in a config file nobody re-checked.
(error) NOAUTH Authentication required.
Applied exercise
Prove the healthcheck itself would have caught a missing password
The healthcheck command already includes -a. Confirm it would fail loudly if that were ever accidentally removed.
- Temporarily edit the healthcheck test command in docker-compose.yml to remove -a hoa_redis_dev_password, leaving a bare redis-cli ping.
- Run docker compose up -d redis and watch docker compose ps — note the reported health status.
- Run docker inspect on the redis container (or docker compose logs redis) and find where the NOAUTH failure surfaces.
- Revert the healthcheck to its original, authenticated form and confirm the service reports healthy again.
Deliverable
A short note recording the container's reported health status with and without the -a flag in the healthcheck.
Completion checks
- Without -a, the container is reported unhealthy after the retry count is exhausted.
- The healthcheck line in docker-compose.yml matches this lesson's version exactly by the end of the exercise.
Why does this lesson require a Redis password in local development, when the container is not exposed outside the developer's own machine?
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.