Engineering the Future of Software
April 2–3, 2017: Training
April 3–5, 2017: Tutorials & Conference
New York, NY

Asynchronous by default, synchronous when necessary

Tomasz Nurkiewicz (Allegro)
4:50pm–5:40pm Tuesday, April 4, 2017
Integration architecture
Location: Grand Ballroom West
Level: Beginner
Average rating: ***..
(3.92, 12 ratings)

Who is this presentation for?

  • Software developers and hands-on architects

Prerequisite knowledge

  • A basic understanding of synchronous communication models in distributed and microservice architectures (RESTful, binary request-response protocols)

What you'll learn

  • Understand the problems with synchronous communication in distributed systems
  • Discover ways to implement asynchronous communication via pub-sub
  • Explore implementation and maintenance challenges


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, and latency. Tomasz Nurkiewicz explains how all of this can be avoided by preferring asynchronous communication between services, pub-sub patterns, and event sourcing.

Too often migrations from monolith to microservices architecture are unsuccessful. Simply replacing in-process method calls with RESTful interfaces doesn’t mean we have a 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 the dependency inversion principle at the architecture level. Moving to asynchronous communication via message passing and pub-sub patterns can prevent temporal coupling. Such coupling requires two systems to exist and work reliably at the same time in order to communicate. This is the biggest challenge in distributed systems that increases complexity, latency, and the possibility of failure.

Tomasz demonstrates how pushing changes asynchronously between systems can improve fault tolerance and make systems more reliable, faster, and more independent, focusing on 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. Along the way, Tomasz covers the drawbacks and challenges of this architectural style.

Photo of Tomasz Nurkiewicz

Tomasz Nurkiewicz


Tomasz Nurkiewicz is a senior software engineer at Allegro. Tomasz has spent half of his life programming (for the last decade professionally in Java land). He loves backend, tolerates JavaScript, is passionate about alternative JVM languages, is disappointed with the quality of software written these days (so often by himself!), and hates long methods and hidden side effects. Tomasz is interested in charting, data analysis and reporting and believes that computers were invented so that developers could automate boring and repetitive tasks. He is involved in open source and used to be very active on StackOverflow. Tomasz is an author, trainer, conference speaker, technical reviewer, and runner and has been recognized as DZone’s most valuable blogger. He claims that code not tested automatically is not a feature but just a rumor.