|
|
|
|
|
|
by airfreak
3013 days ago
|
|
|
I take the opposite view, the microservice anti-pattern is the API explosion. When you start chaining together HTTP REST APIs into wide and/or deep call graphs then you get all kinds of problems: - need complex circuit breaker patterns to deal with API call failures - overall uptime is affected by direct dependencies on a graph of synchronous calls (you are at the mercy of the other APIs for your own uptime) - latency can increase as what could be done asynchronously is done synchronously - developing and testing microservices becomes difficult because of so many dependencies. You start having to develop your own service stubs or evening running the other services. Microservices are about independently deployable units. When you isolate services via message queues you can create services that have many fewer runtime dependencies which can lead to greater decoupling, greater reliability and easier development/testing. You are less likely to end up with a distributed monolith also. |
|
|
If a request comes in from an external system, and that request is queued, then the external system is already not directly impacted by downtime after the queue. Additional latency in processing after the queue is also hidden by the single queue. After a single queue makes the overall system async the goal should be to increase overall throughput and efficiency, and I don't believe only using queues accomplishes that.
I've seen this play out multiple times now, where the engineers decide they are "doing messaging", and use it for everything, even what could be simple request/response REST services. Tuning the overall system for performance becomes complicated, and the messaging brokers have to be scaled out to handle the multiplied load.
On a less serious note, the logistics game Factorio (https://www.factorio.com/) really drives this point home. In a distributed system/assembly line, really large buffers all over the place makes it harder to detect issues and tune throughput.