⭐ Restaurant Service

restaurant-service allocates inventory and makes the saga's approve/reject decision — Kafka-driven only, no HTTP controller. Topics, port, and schema are on the services-reference.html diagram, which also covers the one real structural fork here: its outbox publisher routes to one of two topics by eventType, not a single fixed topic like every other service in this repo.

InventoryItem is the one entity in this repo that doesn't follow the UUID-surrogate-key convention used everywhere else — its itemCode is a genuine natural business key, kept as a String deliberately.

This module's Kafka wiring is what closes the full saga chain end-to-end: order-service → payment-service → restaurant-service, with both upstream services reacting independently to this module's decision. See Saga Flow.

InventoryItem rows are pre-seeded (data.sql, 10 items, two deliberately low-stock) — a real gap the code-review audit caught: nothing else in this repo ever creates one, so without the seed, every real order would hit ITEM_NOT_FOUND unconditionally, the module's core function unreachable in any actual run. This module's audit is in progress — see docs/code-review.md.