The same reservation arrives through more than one path with a different identifier each time, and modifications delivered out of order overwrite state that is newer than they are.
A property taking bookings through several intermediaries relies on a channel manager to deliver them into one system. When it works, nobody thinks about it. When it does not, the failure is either a room sold twice or a room held empty, and both are expensive.
The process
Reservations originate on booking platforms, are collected by a channel manager, and are pushed into the property system as messages: new booking, modification, cancellation. Availability flows the other way. Each platform has its own identifier scheme, its own field names, and its own idea of what a modification means.
Where it breaks
The same reservation arrives more than once. A retry after an ambiguous timeout, a resend after a channel-side correction, or a booking that reaches the property through both the channel manager and a direct interface. If intake keys on the message rather than the reservation, each delivery creates a booking, and the property believes it has sold two rooms to one guest.
Identifiers are not stable across paths. The same reservation carries a platform reference, a channel-manager reference and a property-system reference, and which of these is present depends on how the message arrived. Keying on whichever identifier happens to be populated produces duplicates in one direction and missed matches in the other.
Modifications arrive out of order. Messages can be delivered in a different order from the one they were generated. A modification and its subsequent cancellation can arrive reversed, and a system that applies whatever it receives last will reinstate a cancelled booking. This is the most damaging failure in the set because it is silent: the reservation looks live, the room is held, and nobody discovers otherwise until arrival.
Partial delivery looks like a change. Some platforms send the full reservation on every modification; others send only what changed. Treating a partial message as complete blanks every field it omitted — dates survive, guest details vanish.
Cancellations are inferred rather than stated. Where a cancellation arrives as a status field on an otherwise ordinary update, a parser looking for a cancellation message type will not see it.
How we would build it
Composite identity, resolved once. Every reservation is keyed on the tuple of source platform and that platform’s own reference, with all other identifiers recorded as aliases against it. A message arriving by a different path resolves to the same record because the platform reference is the one identifier that is stable no matter how the message travels.
Idempotent intake. Applying the same message twice produces the same state as applying it once. This is what makes retries safe, and it removes the entire class of duplicate caused by delivery uncertainty — a retry after a timeout is no longer a risk to weigh, it is simply a retry.
Ordering by source timestamp, not arrival. Each message carries the time it was generated at source. State is only advanced by a message newer than the one that produced the current state; an older message is recorded and ignored rather than applied. This alone prevents the reinstated cancellation.
Explicit full-versus-partial handling per channel, configured rather than inferred, so an omitted field is only treated as a deletion where that channel actually means it.
Cancellation detected from status as well as message type, with the two paths tested independently.
What the system proves about itself
Two continuous checks, both cheap.
Reservation count and room-nights held, reconciled against each platform’s own reporting. A divergence here means intake has drifted, and it surfaces within a day rather than at arrival.
An ordering exception log. Every message ignored for being older than current state is recorded. A steady low rate is normal and expected; a spike indicates a delivery problem at the source that the property would otherwise learn about from a guest standing at the desk.
Neither check requires the property system to be modified, and both can run against a read-only extract — which matters, because the systems involved are usually not ones a property is willing to have anybody experiment with.