I’m currently reading The Fundamentals of Software Architecture. The book has opened my eyes to many things regarding software architecture. I wasn’t oblivious, for sure, but it expanded my view on the topic. One thing I came across was the pattern of communication used in microservices architecture. I was on the chapter about Event-Driven Architecture (EDA), where the authors mentioned how this architecture is more responsive, the reason being that it’s asynchronous as opposed to synchronous (REST).
The problem
If Service A calls Service B, but Service B is overwhelmed with requests, then response time will increase. This will cascade — any service depending on A will now also be slow. This reduces responsiveness. Users will be presented with loading spinners, which are most likely to frustrate them, leading to an overall terrible user experience.
Contracts between services are often brittle, and schemas can drift — unless you have something like OpenAPI to help address this issue. If a field is removed, a downstream service that relied on it can break catastrophically without warning.
Failures in one service can propagate upstream, leading to cascading failures in all other services. This is why this type of communication gets a thumbs-down for resilience. If a service that other services depend on is running out of memory or other resources and is running slowly, then services relying on it will also be slow.
How these issues are normally overcome
They’re normally overcome through:
- Circuit breakers
- Retries
- Rate limiting
These are all part of addressing what are known as the distributed systems concurrency fallacies. Networks are not reliable, latency is not zero, and you definitely don’t have infinite bandwidth. Mature ecosystems such as Spring Boot will help you accomplish circuit breakers, retries, and rate limiting in your codebase, so you don’t have to reinvent the wheel and can get battle-tested code.
Why this communication pattern exists
It’s cheap for services to communicate this way, and it’s a model most developers can understand. Synchronous communication is easier to reason about than asynchronous communication. It’s ubiquitous, well-supported, and easy to troubleshoot with tools such as Postman or curl. It’s cheaper since you don’t need an expensive message broker such as a Kafka cluster to manage for EDA.
Summary
I’ve had this hunch for a while that REST-based communication in microservices was problematic, but the book was able to put that into terms I could understand, and it vindicated me. So, networks are flaky and can affect the overall user experience and overall system reliability. There are many great alternatives, such as Event-Driven Architecture, in which services communicate asynchronously via events.