Any architecture decision involves a trade-off. It's no different if you decide to go reactive, e.g. on one side using Reactive Streams implementations gives better resources utilization almost out of the box but on the other hand makes debugging harder. Introducing reactive libraries also has huge impact on your domain, your domain will no longer speak only in terms of Payment, Order or Customer, the reactive lingo will crack in introducing Flux, Flux, Mono (or Observable, Flowable, Single or whatever Reactive Streams publishers your library of choice provides). Such trade-offs quickly become evident but as you can probably guess not all of them will be so obvious - The Law of Leaky Abstractions guarantees that. Reactive libraries make it trivial to change threading context. You can easily subscribe on one scheduler, then execute part of the operator chain on the other and finally hop onto a completely different one. Such jumping from one thread to another works as long as no thread-local state is involved, you know - the one you don't usually deal with on a day to day basis although it powers crucial parts of your services (e.


I guess you came to this post by searching similar kind of issues in any of the search engine and hope that this resolved your problem. If you find this tips useful, just drop a line below and share the link to others and who knows they might find it useful too.

Stay tuned to my blog, twitter or facebook to read more articles, tutorials, news, tips & tricks on various technology fields. Also Subscribe to our Newsletter with your Email ID to keep you updated on latest posts. We will send newsletter to your registered email address. We will not share your email address to anybody as we respect privacy.

This article is related to


microservices,debugging,streams,threading,reactive,local,context