Documentation Index
Fetch the complete documentation index at: https://mintlify.com/microservices-patterns/ftgo-application/llms.txt
Use this file to discover all available pages before exploring further.
The Kitchen Service in the FTGO application represents the restaurant’s kitchen workflow. It manages Ticket aggregates that track the preparation lifecycle of each order, from creation through acceptance, preparation, and pickup. The service participates in the CreateOrderSaga, CancelOrderSaga, and ReviseOrderSaga as a saga participant, and publishes ticket domain events consumed by the Delivery Service. This page covers the service’s responsibilities, domain model, REST API, messaging, and database schema.
Responsibilities
- Create and manage
Ticket aggregates that mirror each food order in the kitchen
- Receive saga commands from the Order Service to create, confirm, cancel, and revise tickets
- Allow kitchen staff to accept tickets via the REST API, specifying an estimated ready-by time
- Publish ticket domain events (
TicketAcceptedEvent, TicketCancelled, etc.) so the Delivery Service can schedule and cancel couriers
- Track preparation lifecycle: acceptance → preparing → ready for pickup → picked up
Domain Model
The core aggregate is Ticket, persisted to the tickets table.
| Field | Type | Notes |
|---|
id | Long | Matches the orderId from the Order Service |
state | TicketState | Current state in the lifecycle |
previousState | TicketState | Saved before entering pending states, used for saga compensation |
restaurantId | Long | The restaurant this ticket belongs to |
lineItems | List<TicketLineItem> | Stored in the ticket_line_items collection table |
readyBy | LocalDateTime | Target ready time set on acceptance |
acceptTime | LocalDateTime | Time the ticket was accepted |
preparingTime | LocalDateTime | Time kitchen began preparing |
pickedUpTime | LocalDateTime | Time courier picked up the order |
readyForPickupTime | LocalDateTime | Time kitchen marked order ready |
Ticket states
CREATE_PENDING → AWAITING_ACCEPTANCE → ACCEPTED → PREPARING → READY_FOR_PICKUP → PICKED_UP
↘ ↘
CANCEL_PENDING REVISION_PENDING
↓
CANCELLED
CREATE_PENDING is the initial state set at construction. The saga’s ConfirmCreateTicket command advances it to AWAITING_ACCEPTANCE. Kitchen staff then call the REST API to move it to ACCEPTED, after which the service emits TicketAcceptedEvent.
The previousState field is critical for saga compensation. When a cancel or revise command puts the ticket into a pending state, the service stores previousState so it can revert cleanly if the saga is rolled back.
REST API
The service listens on port 8083.
| Method | Path | Description |
|---|
POST | /tickets/{ticketId}/accept | Kitchen staff accept a ticket and set an estimated ready-by time |
Accept ticket request body
{
"readyBy": "2026-05-21T18:30:00"
}
readyBy timestamp must be in the future at the time of acceptance. If readyBy is not after the current time, the service throws an IllegalArgumentException and returns an error.
The REST API surface of the Kitchen Service is intentionally minimal — most state transitions happen via saga commands over the messaging layer rather than direct HTTP calls.
Messaging
Events published
Events are emitted on the net.chrisrichardson.ftgo.kitchenservice.domain.Ticket channel:
| Event | Trigger |
|---|
TicketCreatedEvent | Saga’s ConfirmCreateTicket command confirms the ticket |
TicketAcceptedEvent | Kitchen staff accept via POST /tickets/{ticketId}/accept; includes readyBy time |
TicketPreparationStartedEvent | Kitchen calls preparing() on the ticket |
TicketPreparationCompletedEvent | Kitchen calls readyForPickup() on the ticket |
TicketPickedUpEvent | Courier calls pickedUp() on the ticket |
TicketCancelled | Saga’s ConfirmCancelTicketCommand confirms cancellation |
TicketRevised | Saga’s ConfirmReviseTicketCommand confirms revision |
TicketAcceptedEvent and TicketCancelled events are consumed by the Delivery Service to schedule or cancel courier assignments.
Saga commands handled
The service listens on the kitchenService command channel (defined in KitchenServiceChannels.COMMAND_CHANNEL):
| Command | Handler | Description |
|---|
CreateTicket | createTicket() | Creates a new Ticket in CREATE_PENDING state |
ConfirmCreateTicket | confirmCreateTicket() | Advances ticket to AWAITING_ACCEPTANCE |
CancelCreateTicket | cancelCreateTicket() | Rolls back a pending ticket creation |
BeginCancelTicketCommand | beginCancelTicket() | Moves ticket to CANCEL_PENDING |
ConfirmCancelTicketCommand | confirmCancelTicket() | Advances ticket to CANCELLED |
UndoBeginCancelTicketCommand | undoBeginCancelTicket() | Reverts ticket from CANCEL_PENDING to previous state |
BeginReviseTicketCommand | beginReviseTicket() | Moves ticket to REVISION_PENDING |
UndoBeginReviseTicketCommand | undoBeginReviseTicket() | Reverts ticket from REVISION_PENDING to previous state |
ConfirmReviseTicketCommand | confirmReviseTicket() | Applies revised line items and reverts to previous state |
Events consumed
| Source | Event | Handler |
|---|
| Restaurant Service | RestaurantCreated | Builds a local restaurant record for validation |
Database
The Kitchen Service uses MySQL. Key tables:
| Table | Description |
|---|
tickets | The Ticket aggregate: state, restaurant ID, timestamps |
ticket_line_items | @ElementCollection collection table for TicketLineItem entries |
message and received_messages tables.