Assignment 03. RabbitMQ-Driven Order and Payment Workflow

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

Dependency: Extends A2 multi-container gateway

Scenario and assignment objective

Orders should be accepted quickly and then processed by separate background services instead of blocking an HTTP request.

Required system features

1. Add RabbitMQ, a simulated Payment worker and a Notification consumer to Compose.
2. Order POST returns 202/PENDING after durable order insert; publish OrderCreated message with event_id.
3. Define event fields: event_id, event_type, order_id, correlation_id, occurred_at and payload.
4. Payment worker applies a deterministic test success/failure rule, saves result and publishes PaymentProcessed.
5. Notification consumer receives final event; persist or log a completion record.
6. Use manual ACK after processing; bounded retries, dead-letter path and visible queue state.

Implementation guide - suggested steps

1. Create a shared event schema document and service-specific consumers; choose a direct/topic exchange.
2. Add RabbitMQ service with durable queue and management UI in Compose (development only).
3. After Order DB write, publish OrderCreated (document that DB+publish dual-write remains an A3 risk).
4. Write Payment consumer: handle event, simulate result, update persisted payment record, publish outcome.
5. Write status-update handler/consumer in Order and notification consumer; expose GET /orders/{id}.
6. Run a worker-failure experiment before ACK; verify redelivery and explain at-least-once behavior.

Hints (not complete solutions)

• Start with one queue and one consumer, then split event roles.
• Use manual ACK only after durable business state update; test crash before acknowledgement.
• An event_id is required now; A4 adds durable deduplication of repeated event_id.
• A DB write and broker publish are two separate operations; discuss a transactional outbox or reconciliation fix.

API / data contracts

• POST /orders returns 202 + order_id; GET /orders/{id} shows PENDING/CONFIRMED/REJECTED.
• Event envelope field names are stable; use routing keys such as order.created and payment.processed.

Mandatory verification and failure experiments

1. Happy path PENDING -> CONFIRMED; rejected payment -> REJECTED.
2. Stop Payment worker before ACK, then restart and observe broker redelivery.
3. Send a deliberately malformed event and verify it is rejected/dead-lettered rather than repeatedly looping.

Required individual submission

• Updated Compose, event schema, workers, retry/dead-letter policy, sequence diagram.
• Automated workflow tests, queue monitoring evidence and limitation note on duplicate events.

Acceptance checklist

• Order workflow asynchronous and observable via polling endpoint.
• Worker interruption does not silently lose a message under stated settings.
• Documented at-least-once behavior and error handling.

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