Role And State Boundaries In Marketplace Systems
A marketplace is not only a catalog. It coordinates several actors who can perform different actions at different stages of a booking.
Authorization and workflow state must be designed together.
Roles Do Not Replace State Rules
A provider may be allowed to manage bookings, but not every booking action should be available at every time.
For example:
| Current state | Customer action | Provider action | Admin action |
|---|---|---|---|
| requested | cancel | accept or decline | review |
| accepted | view status | start service | intervene |
| in progress | view status | complete | intervene |
| completed | review | view history | resolve dispute |
Permissions answer who. State transitions answer when.
Keep Transitions On The Backend
The interface may hide invalid buttons, but the backend must enforce transitions.
typescriptfunction canTransition(role: Role, from: Status, to: Status): boolean {
return transitionPolicy[role]?.[from]?.includes(to) ?? false;
}This prevents clients from creating invalid operational states.
Notifications Follow Confirmed State
Notifications should be triggered after a transition is persisted, not before. A message saying a booking was accepted is incorrect if the database write later fails.
Store notification intent separately so delivery can retry without repeating the booking transition.
Payment Coordination Needs Explicit Status
Even when payments are handled by another provider, the application needs states such as pending, authorized, paid, failed, or refunded.
Payment state should not be inferred only from booking state.
Engineering Outcome
Marketplace reliability comes from combining role boundaries, state machines, transactional changes, and retryable side effects. UI permissions alone are not architecture.