FSM on steroids: how we tamed 16+ room statuses
In PDP, we built a finite state machine for the room lifecycle: 16+ states, nonlinear and reverse transitions, protected statuses, and coordination with 4+ subsystems through an event-driven approach.
In PDP, we built a finite state machine for the room lifecycle: 16+ states, nonlinear transitions, and even reverse ones. It sounds like an ordinary workflow, but in practice it was a quest on the level of “why did the status suddenly roll back on Friday at 18:47.”
Our transitions depend on context: acceptance type, defect severity, and whether there are active remarks. The most important part was isolating 7 protected statuses that do not roll back because a remark was created late. Otherwise, you can end up not just with a bug, but with a legally risky situation.
Under the hood, this is coordination with 4+ subsystems through an event-driven approach. We also handled race conditions separately, so events wouldn’t turn into a deadlock disco and break the business logic.
Against the backdrop of the hype around reliable distributed workflows, this once again confirms that sometimes the best “AI” in a system is a well-designed FSM 😄