Reactive programming is powerful - but it’s not the default answer to every backend problem. I’ve seen both extremes: using it everywhere vs avoiding it completely. In reality, it works best in specific cases. Reactive programming is especially useful when: ▪️ your service spends a lot of time waiting on I/O ▪️ you need to handle many concurrent requests ▪️ you work with streaming data or event-driven flows For example, processing Kafka streams, building a notification system with fan-out to multiple services, or aggregating data from several APIs in parallel — these are scenarios where reactive really shines. In such cases, it improves throughput and resource utilization because threads aren’t blocked waiting for I/O, which makes the system behave more predictably under load. At the same time, this comes with a cost. The code becomes harder to read and debug, the mental model is less intuitive, and onboarding new engineers takes longer. If part of your system is still blocking, you may also lose most of the benefits. That’s why I don’t see reactive as a better default. For many services — especially simple CRUD — synchronous code is easier to build, support, and evolve. The real question is not “Is reactive better?” It’s “Do we actually need it here?” What’s your experience with reactive programming - real advantage, unnecessary complexity, or both? #reactiveprogramming #java #kotlin #spring #webflux #backend #softwareengineering
The onboarding cost is real and often underestimated. Reactive code that a senior wrote in a day can take a new engineer a week to understand — and that debt compounds every time the team changes.
The 'mental model' point is key. I've seen teams struggle for weeks with backpressure issues that wouldn't even exist in a standard thread-per-request model. 'Do we actually need it?' should be the first question in every design doc before jumping into reactive streams.
Well said. Reactive is a tool, not a religion. I have seen teams adopt it for simple CRUD services and end up with code that nobody can debug. The sweet spot is exactly what you describe — use it where backpressure and async streams actually matter, keep the rest simple and readable.
I completely agree with the "fit for purpose" idea. Reactive is great where there's I/O and high competition, but as a default, it often overcomplicates things. Ultimately, the winner isn't the one using Reactive, but the one who chose the right tool for the task
onboadrding is really caretaking thing
You can say anything on this level of abstraction.
Great take. Reactive really shines when you’re I/O‑bound, highly concurrent, or dealing with streams — but forcing it into simple CRUD adds more cognitive load than value. For most services, synchronous code stays clearer and easier to evolve, while reactive becomes a strategic tool for the right hotspots. In practice, it’s rarely “reactive everywhere” or “never reactive” — it’s about using it where the system actually benefits.