How do you decide where one service ends and the next begins, and when is a modular monolith the more honest answer?
Answer
Short answer
Draw boundaries on data ownership so exactly one service writes each table, then accept that a workflow crossing them needs a saga of compensating steps and an outbox to make the write and the publish atomic.
Microservices are useful only when the service boundaries match ownership and change patterns. Good microservices design asks which data changes together, which team owns the decisions, and where transactions need to end. Weak service boundaries split code by nouns and create distributed transactions. Strong service boundaries may lead to microservices, a modular monolith, or a hybrid, depending on where coordination is cheapest.
Microservices should reduce coordination, not multiply it across a transaction.
Was this answer helpful?
Likely follow-ups
- Two services keep needing the same customer record. What are your options besides sharing the table?
- A saga's compensating step fails. What now?
- How would you extract one service out of an existing monolith without a big-bang cutover?
- Your consumers receive the same event twice. Whose problem is that, and where is it solved?
Related questions
- How do you decide between a modular monolith and microservices?hardAlso on modular-monolith and microservices4 min
- A teammate says a saga can just roll everything back if step four fails. What is wrong with that, and what would you tell them to build instead?hardAlso on saga and microservices5 min
- Two teams own two services that talk to each other. How do you stop one breaking the other without running both together in a shared environment?mediumAlso on microservices4 min
- One screen needs data owned by three different services, and it has to render in 200 milliseconds with a filter and a sort applied. How does that request get served?hardAlso on microservices6 min