Resilient
Build safer and more resilient distributed services.
Query/Response
For Spring® AMQP
A messaging pattern for building highly decoupled evolving service architectures.
For Spring® AMQP
A messaging pattern for building highly decoupled evolving service architectures.
Sometime around 2015 I came across a presentation with Fred George, about the Challenges in Implementing Microservices. It's a great talk, with lots of good and relevant information. Experience comes from learning through failures, and at this point in time I had just learned a hard lesson about the problems with distributed services and blocking API calls. I had seen how latencies would go up and availability go down the drain, as calls from service A to B were actually depending on service B calling service C, calling service D. It was a mess.
In his talk George lands at the question "Synchronous or Asynchronous?" and proceeds to describe, what he calls, the "Needs Pattern". Service A would, instead of calling service B, publish a query, and service B would listen for it and send back a response. After hearing this I began to think a lot about the effects of moving to asynchronous communication between services. There was clearly a lot more there than just decoupling. Something more fundamental.
The Query/Response pattern, that I arrived at, challenges developers to really think hard about the responsibilities and autonomy of services. It provides very few guarantees, which will force decisions around resilience and availability at a much earlier stage in the design and development process. It literally turns things around - an inversion of responsibility - which I truly believe we can benefit from.
Olle Törnström, 2019