Rethinking Reactive Architectures - David Leitner - NDC Oslo 2021

Modern web architectures are amidst a paradigm shift — more and more web applications are built upon asynchronous and reactive patterns. This movement is understandable, as it takes scalability, resilience, and real-time integration to an elusive new level. Unfortunately, we observe that many new customer projects only use parts of this paradigm shift sensibly. Thus, they often end up with an only partially reactive architecture that introduces a lot of new complexity without allowing us to utilize the full potential of reactivity.

In this talk we will focus on the reactive paradigm's central concepts, core ideas, and the corresponding manifest and make them understandable. Based on this knowledge, we will go into detail by mapping it to concrete patterns, like event-centric persistence, the concept of hydrations or projections, and the shift of creating systems in a fully push-based design from end-to-end.

Upon a closer look at the advantages and challenges we've experienced in customer projects, it turns out that reactive architecture is not a silver bullet either. Rather, they are suited for a specific set of problems. In a nutshell, reactive architectures can be a game-changing tool to build cloud-native, highly responsive, and resilient applications. This talk will give you the needed knowledge to decide if it's the right one for the job.

Check out more of our featured speakers and talks at

[boldisj]

Most of concepts I already knew, however nicely packed together. Looking at sharding as another layer of scalability I really like.

[russellf]

Excellent talk. It should have been titled, “The correct way to build microservices”.

[MidnightSt]

"destiny operator" - nice, a new fancy name for functions.

[ksin]

Great talk. How does one track what is going on 'overall' and if there are any issues? Assuming we write these reactive services around customer journey/stories ("use-cases") - and we end up splitting processing of various steps of the journey amongst several reactive microservices (at some well-considered appropriate level of granularity). Now how best do we track, say a user transaction for use-case A, which had 4 stages to be processed by 4 different reactive microservices - at which stage the processing is at the moment for the user? How many such transactions completed (and at what rate - as ultimately the customer may care about overall latency in processing her requests)? How many are in what stage? Is the stream processing going smoothly at some desired rate? Is there a bottleneck developing? "What is going on in my system"?