One guest record across the stay

Most hospitality stacks are a collection of tools that happen to share a building. Reservations live in a PMS. The restaurant keeps its own tickets. Room service is a phone call that may or may not become a folio charge. By morning, the night audit is an argument.

The fix is not another integration. It is a boring decision: there is one guest, one stay and one folio. Everything else is a view of that record.

What has to be shared

When I work on StayBoard, the hard part is not drawing screens. It is deciding which objects the whole product is allowed to disagree about. Rooms, rates and guests cannot fork. Kitchen tickets can — they are events. Folio lines cannot — they are money.

• A reservation creates the stay. Check-in does not invent a second guest.
• A room-service order posts to the same folio the front desk already has open.
• Housekeeping status is a property of the room, not a chat message.
• Night audit closes a business date, not a spreadsheet export.

APIs follow the record, not the screen

If the guest portal can order breakfast, it should not talk to a separate “orders database”. It should create a charge against the stay the PMS already knows. The restaurant display can be its own service. The money cannot.

That is why I reach for Spring Boot services with explicit boundaries and a shared data model, not a pile of microservices that each keep a copy of the guest. Distribution is a cost. Pay it when the load requires it — not because a diagram looked impressive.

The result, when it works, is quiet. The kitchen sees the ticket. The folio already has the charge. The guest did not need a new account. That is the kind of architecture I want to be judged on.