Assignment 02. NGINX Gateway, Compose and Stateless API Scaling

Week 4 · Assignment brief from the course outline; submission and evaluation results have not been recorded.

Dependency: Extends A1 Order + Restaurant Services

Scenario and assignment objective

The Order API needs two replicas but all customers must observe shared order history and a stable public API.

Required system features

1. Add Compose services for nginx, order-api-1, order-api-2, restaurant-api and postgres.
2. Persist orders in PostgreSQL; two Order replicas share the Order DB (never per-container memory).
3. Create a dedicated schema/database for Order ownership; Restaurant owns its own catalogue data/seed.
4. Configure NGINX: /orders routes to Order upstream, /restaurants routes to Restaurant, forwards correlation header.
5. Expose only NGINX to the host; internal application and database ports stay on Compose network.
6. Add named volume for Postgres and /healthz on APIs; instance_id visible in logs/headers.

Implementation guide - suggested steps

1. Copy working A1 services into the same repository; preserve public request/response contracts.
2. Add SQL migration for orders, items and request IDs; replace in-memory repository with PostgreSQL adapter.
3. Write compose.yaml with fixed two Order replicas and DNS service names; use environment variables for DB DSN.
4. Create nginx.conf with upstream containing both Order services and locations for /orders and /restaurants.
5. Launch the stack, run repeated requests, inspect per-instance access logs and validate shared state.
6. Stop an Order replica, test gateway behavior, restart it and verify data durability across restarts.

Hints (not complete solutions)

• Use Postgres UNIQUE constraints for IDs; database connections are per process, not per HTTP request.
• To prove load balancing, add X-Instance-ID response header and inspect nginx upstream addresses/logs.
• Use Docker Compose service names as DNS hostnames and a named volume for database persistence.
• A simple static upstream can require NGINX reload/restart after container IP changes; document the behavior.

API / data contracts

• Public /orders and /restaurants API unchanged; GET /healthz on each API.
• Compose startup: docker compose up --build -d; teardown: docker compose down.

Mandatory verification and failure experiments

1. Send repeated requests through http://localhost:; observe both Order replicas.
2. Create via one instance and read via gateway across both: same data.
3. Restart stack: stored order remains; stop one replica: surviving instance responds.

Required individual submission

• compose.yaml; nginx.conf; migrations; persistent storage; individual README and recorded routing evidence.
• At least six integration tests and short failure behavior note.

Acceptance checklist

• All services start from one documented command.
• NGINX routes correctly; two API replicas use one durable Order data store.
• Expected failure and restart experiments pass.

Marks: 6 / 40 lab marks. Use the common rubric: implementation 40%, tests 25%, fault experiment 20%, documentation/viva 15%.