We split an order platform into eleven services and ended up with the costs of microservices and the coupling of a monolith. The symptoms that gave it away, lock-step deploys, a shared database and chatty call chains, how we measured them, and the boundary changes that fixed them.
Splitting a system gets all the attention; merging services back is treated as failure. It is not. The signals that a service boundary is in the wrong place, the step-by-step plan we used to merge pricing, promotions and tax without downtime, and what improved afterwards.
Retries fix brief failures and amplify long ones. The rules our platform team uses: which status codes and errors are safe to retry, exponential backoff with full jitter, a retry budget per client, and retrying at one layer only so three hops do not turn one failure into 27 calls.
Event-driven is not one pattern but four, and teams get hurt when they mix them up. We compare event notification, event-carried state transfer, event sourcing and CQRS on one billing example, with the costs each one adds and the signals that tell you which fits.
A proposal to split our Django monolith into 30 services landed on day one of planning. We said no, then spent 14 months extracting four services with a strangler fig: boundaries inside the monolith first, routing at the edge, shadow traffic, and data ownership moved last.