Microservices and service decomposition

Start with whether you should

A large amount of microservice pain comes from systems that were split before anyone understood where the seams were. A monolith with clear internal modules is a better position to be in than six services that all write to the same database and have to be deployed together. That second thing is not a microservice architecture, it is a monolith with network calls in the middle and worse failure modes.

So the first conversation is usually about whether decomposition is the right move at all. Good reasons exist: parts of the system have genuinely different scaling profiles, different teams need to release independently, or one component has a reliability requirement the rest does not. "It is more modern" is not one of them, and we will say so.

Finding boundaries that hold

Boundaries drawn around technical layers tend to fail. Boundaries drawn around business capabilities tend to hold, because they change for the same reason at the same time. The test we apply is whether a typical change request lands inside one service. If a routine change means editing four services and coordinating their release, the boundaries are in the wrong place, and no amount of tooling will fix that.

Data ownership follows the same rule. Each service owns its data and nothing else reads it directly. Shared database tables are the fastest way to turn independent services back into a distributed monolith, because now a schema change is everyone's problem and nobody can deploy alone.

Messaging, and the failures it introduces

Once calls cross a network they can be slow, they can fail halfway, and they can arrive twice. Design that assumes otherwise breaks in production in ways that are unusually hard to reproduce.

Asynchronous messaging is the default for anything that does not need an answer immediately, which is more things than people expect. It decouples availability: a consumer being down becomes a queue getting longer rather than a customer seeing an error.

Handlers are idempotent. Every message carries an identifier and processing the same one twice produces the same result as processing it once. This is not optional. At-least-once delivery means duplicates will happen, and the only question is whether the system was built expecting them.

Failures go somewhere visible. Messages that cannot be processed land in a dead-letter queue with enough context to understand why, and somebody is alerted. A silently discarded message is a data-loss incident that nobody has noticed yet.

Consistency is chosen, not assumed. Where a workflow spans services, we decide explicitly how it recovers from a partial failure and write that decision down, rather than hoping the happy path is the only path.

Keeping it debuggable

The real cost of distributing a system is that debugging gets harder. A request that used to be one stack trace is now spread across four services and a queue. That cost is worth paying only if you invest in seeing across the whole thing.

A correlation identifier is generated at the edge and travels with the work through every hop and every message, so one identifier reconstructs the whole journey. Each service exposes a health endpoint that reflects real dependency state rather than returning a cheerful two hundred while its database is unreachable. Metrics cover queue depth, consumer lag and error rate, because those are the numbers that move first when something is going wrong.

How we take this on

Usually incrementally, and usually starting from something that already exists. A capability is identified, given its own data and its own deployment, and moved out behind a stable interface while the original system keeps running. Then the next one. A staged extraction can be paused, and a paused extraction still leaves you with a working system. A big-bang rewrite offers neither.