State Machines (Finite State Machines or FSMs) are a fundamental concept in computer science. They describe a system that can be in exactly one of a finite number of states at any given time. In software development, we use them to ensure that an Order cannot go from 'Refunded' back to 'Shipped', or that a UI component doesn't try to fetch data while it is already in an 'Error' state.

Mermaid stateDiagram-v2

Mermaid offers `stateDiagram-v2` for rendering these models. It supports simple transitions `[*] --> State1` as well as complex nested states and concurrency.

Complex Order Fulfillment Lifecycle

Let's model an Amazon-style order lifecycle. This involves happy paths (Placed -> Shipped) and edge cases (Returned, Lost).

Choice Pseudostates

Sometimes a transition depends on a dynamic condition. In UML state diagrams, this is a diamond. In Mermaid, we define it with `<<choice>>`.

stateDiagram-v2
    state if_verified <<choice>>
    [*] --> Verify
    Verify --> if_verified
    if_verified --> Dashboard : Verified
    if_verified --> Login : Failed

Using state diagrams proactively in your design phase can save dozens of hours of debugging race conditions later. They force you to think about 'What happens if the user clicks this button while the previous request is still pending?'

Concurrency, Guards, and Timeouts

Modern UIs and backend workflows often juggle concurrent requests. Use guards to make concurrency explicit: block transitions unless prerequisites are met, and document timeouts so flows self-heal instead of getting stuck in limbo.

• Add `[*] --> Error` transitions for timeout states to avoid silent hangs.
• Model optimistic UI states (e.g., "Saving...") so you can test rollback paths.
• For payments, add a "Chargeback" or "Dispute" branch so finance teams see post-fulfillment complexity.