Assignment 01. Containerized Order and Restaurant Services

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

Dependency: New system foundation

Scenario and assignment objective

Customers browse restaurants and create orders. Two isolated services must communicate reliably across an HTTP boundary.

Required system features

1. Restaurant Service: GET /restaurants and GET /restaurants/{id}; seed >=3 restaurants and >=6 items.
2. Order Service: POST /orders and GET /orders/{id}; validate restaurant and item IDs by calling Restaurant Service.
3. Reject bad quantities, missing fields, nonexistent entities and unavailable downstream service with correct HTTP responses.
4. Generate unique order_id and correlation_id; return JSON with order_id, status and created_at.
5. Write separate Dockerfiles for both services; use a non-hardcoded RESTAURANT_URL env variable.
6. Accept >=20 concurrent requests without corrupting order state; /healthz for both services.

Implementation guide - suggested steps

1. Create folders services/order and services/restaurant with separate main entrypoints and minimal README.
2. Write an API contract, request/response JSON examples and seed catalogue first.
3. Implement the Restaurant read-only endpoints, then Order validation and Order in-memory store protected by a mutex (A1 only).
4. Call Restaurant using an HTTP client with a short configured timeout and explicit 4xx/5xx mapping.
5. Write one Dockerfile per service; build images and run containers on a user-defined Docker network.
6. Create automated API tests for success, validation, concurrency and unavailable dependency.

Hints (not complete solutions)

• The Order process must not call a Restaurant function directly; use an actual HTTP request.
• Run the two services independently with different ports. In Docker, localhost inside Order is NOT Restaurant.
• Store order records behind a mutex or use a concurrency-safe map; the state will migrate to PostgreSQL in A2.
• Propagate correlation IDs in requests and logs so a cross-service request is traceable.

API / data contracts

• POST /orders: {restaurant_id,items:[{menu_item_id,quantity}]} -> {order_id,status,created_at}.
• Recommended errors: 400 malformed input, 404 restaurant/item missing, 503 dependency unavailable.

Mandatory verification and failure experiments

1. 20 concurrent POSTs yield 20 unique IDs, no race/panic.
2. Stop Restaurant; order submission returns a bounded failure (no indefinite hanging).
3. Start both containers without local installed Go and retrieve created orders.

Required individual submission

• Individual private repository; service code; two Dockerfiles; README; API examples.
• At least six automated test cases plus example logs of outage experiment.

Acceptance checklist

• Both APIs run independently in containers.
• Order requests call Restaurant through HTTP and handle failure predictably.
• Concurrency, request validation and reproducible startup pass.

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