Designing an Order Workflow: Putting the Patterns Together
Boundaries, communication styles, technology, and sagas all sound reasonable in isolation. Here’s what it looks like to actually apply all four decisions to one real workflow, in order.
Boundaries, communication styles, technology, and sagas all sound reasonable in isolation. Here’s what it looks like to actually apply all four decisions to one real workflow, in order.
Splitting a monolith means splitting its database transactions too. The instinct is to reach for a distributed transaction. Here’s why that instinct is usually wrong, and what to do instead.
The communication style (sync/async, request-response/event-driven) narrows the field. Here’s how the actual technologies stack up once you’re choosing among them.
In a monolith, a stack trace tells you what went wrong. In microservices, you’re grepping across three services’ logs at 2 AM trying to figure out which one lost the request. Here’s how to make that possible instead of painful.
In a monolith, renaming a field means updating all callers in one commit. In microservices, consumers upgrade on their own schedule, so your API has to evolve without breaking the ones that haven’t upgraded yet. Here’s how.
You split the monolith into twelve services. Now a new developer’s first week is spent getting Docker Compose to run all twelve on their laptop, and half of them crash because of a port conflict. Here’s how to make local development work without the pain.
In a monolith, deploy means pushing one thing. In microservices, every service deploys independently, which is the whole point, until you realize that ‘independently’ also means ‘without knowing what the other services are doing right now.’
Each service owns its database. That’s the rule. But when a report needs data from four services, or a customer wants to see their complete order history, you’ve got a query problem that a single SELECT can’t solve. Here’s how to handle it.
A service mesh gives you mTLS, traffic management, and observability without changing application code. It also gives you another piece of infrastructure to operate, debug, and explain to new hires. Here’s how to tell whether the trade-off is worth it.
Before picking REST, gRPC, or Kafka, you need to answer a more basic question: does this interaction block, and does the caller expect an answer? Get that wrong and no technology choice saves you.