The accepted answer is not accurate. OP is asking for a "real time use case". Normally in such system you don't store seat reservation in memory and for the lock to make sense it must be made on an entity. In a real system this will always be used by a transaction in some persistent store, with either explicit lock or some optimistic strategy. Accurate example must point to a need of thread synchronization in application memory. Something like cache for the idempotent request verification or WebSocket session storage fit the criteria.