Reach for a Queue Before You Reach for Microservices
Most of the reliability people chase with microservices, they can get from a monolith and an honest queue. The work was always asynchronous — the queue just admits it.
When a monolith starts hurting, the reflex is to reach for microservices. More often, the thing that actually hurts is a handful of request paths pretending to be synchronous when they never were.
Emails, exports, notifications, third-party fan-out, reconciliation — none of that needs to happen inside the user's request. Pushing it onto a queue (RabbitMQ, in the systems I've built) is the cheapest reliability win I know.
You keep the simplicity of one deploy and one database, and you get back the two things you were really after: requests that stay fast, and background work that can retry without taking a user down with it.
Microservices are a real tool with a real cost — network boundaries, deploys, observability, distributed failure. Reach for a queue first. Reach for services only when the queue genuinely isn't enough.
