Asynchronous by default, synchronous when necessary

Asynchronous by default, synchronous when necessary


In distributed systems synchronous communication (RPC-style) is tempting but can quickly get out of hand. Suddenly you need to think about retrying, fallbacks, circuit breakers, failover, latency. All of this can be avoided if we prefer asynchronous communication between services, pub-sub patterns and event sourcing.
Too often I see unsuccessful migration from monolith to microservices architecture. Simply replacing in-process method calls with RESTful interfaces doesn’t mean we have distributed system consisting of loosely coupled independent services. Quite the opposite: our architecture is now a tangled web of interconnected, slow, chatty and unreliable components. Dozens of patterns were introduced to ease the pain like circuit breakers, scaling services horizontally and load balancing. All of this to prevent cascading failures and increased latencies.
We can achieve fast, loosely coupled, independent services only if we apply dependency inversion principle at the architecture level. By moving to asynchronous communication via message passing and pub-sub patterns we can prevent temporal coupling. Such coupling requires two systems to exists and work reliably at the same time in order to communicate. This is the biggest challenge in distributed systems that increases complexity, latency and possibility of failures.
During the presentation I’ll show you how pushing changes asynchronously between systems can improve fault tolerance, make systems more reliable, faster and independent. The core idea I’m going to present is publishing (pushing) changes and rebuilding state on the client side as opposed to pulling data when needed. From this point jumping to event sourcing is quite natural.
We will not forget about drawbacks and challenges of this architectural style.

Speaker: Tomasz Nurkiewicz