Und so begann die große Reaktion. Die reaktive, um genau zu sein.
Reactive Streams, Spring WebFlux, Project Reactor – diese Begriffe avancierten in den letzten Jahren zu den Losungsworten einer ganzen Entwicklergeneration, die entschlossen war, Threads zu befreien, I/O zu entfesseln und Millionen gleichzeitiger Verbindungen mit der Gelassenheit eines Zen-Meisters zu verwalten. Das Versprechen klang verlockend: Statt eines Threads pro Request jongliert ein Event-Loop mit wenigen Threads Tausende von Anfragen – elegant wie ein Schweizer Uhrwerk, komplex wie ein Schweizer Steuerrecht.
Wer je versucht hat, einen reaktiven Stack von Grund auf zu verstehen, kennt den Moment der Erleuchtung – oder genauer: den langen, dunklen Tunnel davor. Flux<T> und Mono<T> klingen zunächst wie Charaktere aus einem Science-Fiction-Roman. Backpressure klingt nach dem, was man nach einem besonders intensiven Sprint-Review verspürt. Und eine Operator-Kette aus flatMap, switchIfEmpty, onErrorResume und publishOn liest sich wie ein Gedicht von Kafka – gemeint ist Franz, nicht Apache, obwohl beide für ihre eigentümliche Komplexität berühmt sind.
Doch der Aufwand lohnt sich. Wer den reaktiven Rubikon einmal überquert, baut Systeme, die unter Last nicht einknicken, sondern fließen. Backpressure – dieses wunderbare Konzept, das dem Datenstrom sagt: „Langsam, Freundchen, ich bin noch nicht fertig mit dem letzten Paket“ – schützt vor dem Ertrinken im Datenmeer. Spring WebFlux, gestützt auf Netty und Project Reactor, liefert die Infrastruktur für genau jene Cloud-native Anwendungen, die heute Microservice-Landschaften bevölkern wie Tauben einen Bahnhofsvorplatz: zahlreich, autonom und gelegentlich schwer zu koordinieren. Wer einmal erlebt, wie ein reaktives System unter extremer Last einfach weiterkämet, während sein blockierendes Pendant längst nach Luft schnappt, begreift den Reiz dieses Paradigmas.
Trotzdem verdient die Schattenseite ehrliche Worte. Debugging in reaktiven Systemen gleicht bisweilen einer archäologischen Ausgrabung: Man gräbt sich durch verschachtelte Operator-Ketten, verliert den Stack Trace irgendwo zwischen zwei flatMap-Aufrufen und fragt sich, welcher Thread eigentlich gerade wen aufruft – und warum niemand zurückruft. Teams, die reaktive Programmierung einführen, investieren Wochen, manchmal Monate, bevor die ersten produktionsreifen Flows entstehen. Die Lernkurve ist keine Kurve. Sie ist eine Wand. Eine sehr hohe, sehr glatte Wand – mit dem Versprechen einer wunderschönen Aussicht ganz oben. Oben angekommen, entdeckt manch ein Team zu seinem Erstaunen, dass die Aussicht zwar grandios ist – der Weg nach unten aber genauso steil.
Und dann kam Project Loom. Und mit ihm Virtual Threads. Und plötzlich flüsterte die Java-Welt eine Frage, die sich anfühlte wie Ketzerei: „Was, wenn wir einfach wieder blockieren dürfen?“
Man muss die Ironie würdigen: Jahrelang konditionierte die Community Entwickler darauf, das Wort „blockierend“ auszusprechen wie einen Fluch. Blocking I/O galt als Erzfeind, der Thread-Pool als überfülltes Wartezimmer, das es zu meiden galt. Und nun – mit Java 21 und Virtual Threads, die im Gegensatz zu Platform Threads so leichtgewichtig sind, dass die JVM Millionen davon erzeugt wie Objekte in einer schlecht optimierten Inner Loop – nun darf man wieder blockieren. Ja, man soll es sogar. Einfacher Code, natürliche Stack Traces, kein mentaler Overhead beim Lesen einer Operator-Kette. Benchmarks aus 2025 belegen, dass Virtual Threads in vielen I/O-lastigen Szenarien mit WebFlux mithalten oder es sogar übertreffen. Das fühlt sich an wie die Nachricht, dass Drucken doch schneller ist als jahrelang mühsam erlernte Kursivschrift – und dass man die Kursivschrift trotzdem für Hochzeitseinladungen braucht.
Ein Paradigma ohne Werkzeuge ist wie ein Architekt ohne Bleistift – theoretisch brillant, praktisch nutzlos. Deshalb lohnt ein Blick auf das Ökosystem, das reaktiven Java-Entwicklern heute zur Verfügung steht.
Project Reactor bleibt das Fundament. Als Referenzimplementierung der Reactive Streams Specification liefert es Mono und Flux, einen reichen Satz an Operatoren und eine tiefe Integration in Spring Boot und WebFlux. Die 2025er Release-Trains bringen kontinuierliche Verbesserungen in Operator Fusion und Garbage-Collection-Optimierung.
RxJava hält sich wacker, besonders in Legacy-Codebases und Android-nahen Projekten. Wer komplexe Datenstrom-Choreographien aus der Vor-Reactor-Ära pflegt, schätzt seine Stabilität und seinen riesigen Operator-Katalog.
Mutiny, das reaktive Herz von Quarkus, verfolgt einen anderen Ansatz: weniger Operatoren, dafür intuitivere API-Oberflächen. Quarkus selbst – das „Supersonic Subatomic Java“-Framework – vereint reaktive und imperative Programmierung unter einem Dach, startet in Millisekunden und eignet sich hervorragend für serverlose Szenarien, in denen Cold-Start-Zeiten über Erfolg und Misserfolg entscheiden.
R2DBC löst das ewige Problem des reaktiven Datenbankzugriffs auf relationale Systeme. Wer einen vollständig nicht-blockierenden Stack aufbauen möchte, aber auf PostgreSQL oder MySQL angewiesen ist, findet hier seinen Verbündeten – und vermeidet den peinlichen Moment, in dem ein blockierender JDBC-Aufruf den gesamten Event-Loop zum Stottern bringt.
Apropos Stottern: BlockHound ist das Gewissen des reaktiven Entwicklers. Als Java-Agent überwacht es zur Laufzeit jeden Thread und schlägt Alarm, sobald ein blockierender Aufruf in einem nicht-blockierenden Kontext auftaucht. Wer BlockHound in seine CI/CD-Pipeline integriert, schläft ruhiger – und findet blockierende Sünden, bevor sie in die Produktion wandern. Reactor-tools ergänzt das Arsenal um bessere Stack Traces und Debug-Hooks, die das eingangs erwähnte archäologische Debugging spürbar erträglicher gestalten. Kotlin Coroutines schließlich fungieren als elegante Brücke: Sie übersetzen reaktive Flows in sequenziell lesbaren Code, ohne die nicht-blockierende Semantik aufzugeben – ein Friedensangebot zwischen den Lagern.
Ein reaktiver HTTP-Endpunkt allein macht noch keine reaktive Anwendung. Wer wirklich von den Vorteilen des Paradigmas profitieren möchte, muss den reaktiven Durchstich konsequent durch alle Schichten ziehen – von der HTTP-Schicht über die Geschäftslogik bis hinunter zur Datenbank. Ein blockierender JDBC-Aufruf tief im Service-Layer genügt, um den gesamten Event-Loop zu blockieren und die mühsam erkämpfte Skalierbarkeit zunichtezumachen. Reaktive Architektur duldet keine halbherzigen Kompromisse.
CQRS – Command Query Responsibility Segregation – harmoniert besonders gut mit reaktiven Systemen. Die Trennung von Schreib- und Lesepfad erlaubt es, beide Seiten unabhängig zu skalieren und mit unterschiedlichen Datenspeichern zu optimieren. Event Sourcing ergänzt dieses Bild: Statt den aktuellen Zustand zu persistieren, speichert das System jede Zustandsänderung als unveränderliches Ereignis. Ein Flux von Domain Events fließt natürlich durch eine solche Architektur, speist Read Models und treibt Projektionen an. Das Axon-Framework bietet hierfür eine ausgereifte Implementierung im Spring-Ökosystem.
Das Saga-Pattern adressiert die unvermeidliche Frage verteilter Transaktionen: Wie koordiniert man einen Geschäftsprozess, der mehrere Microservices berührt, ohne eine zentrale Datenbanktransaktion? Die Antwort lautet: durch eine Sequenz lokaler Transaktionen, die über Events kommunizieren, und durch kompensierende Transaktionen, die im Fehlerfall rückabwickeln. Choreographie-basierte Sagas fließen natürlich durch reaktive Event-Streams; orchestrierungsbasierte Sagas profitieren von der Lesbarkeit eines zentralen Koordinators. Spring Cloud Gateway, selbst auf WebFlux aufgebaut, übernimmt die Rolle des reaktiven Türstehers vor der gesamten Microservice-Landschaft – und leitet eingehende Ströme dorthin, wo sie hingehören.
Wer glaubte, reaktive Programmierung sei ein Nischenthema für Hochlast-Backends, erlebt gerade eine unerwartete Renaissance – und ausgerechnet die KI-Welle treibt sie an. Große Sprachmodelle liefern ihre Antworten nicht als monolithischen Block, sondern Token für Token, in einem kontinuierlichen Strom, der auf Verarbeitung wartet. Und was eignet sich besser für einen kontinuierlichen Strom als ein Flux<String>?
Spring AI, seit Mai 2025 in der Version 1.0 GA verfügbar, nutzt genau diesen Ansatz. Sein ChatClient liefert LLM-Antworten als reaktiven Stream – Token für Token, direkt in die HTTP-Response, via Server-Sent Events über WebFlux. Der Nutzer sieht die Antwort entstehen, Wort für Wort, statt auf einen Ladebalken zu starren. LangChain4j, der zweite große Akteur im Java-KI-Ökosystem, geht denselben Weg: StreamingChatModel und StreamingChatResponseHandler koppeln sich nahtlos an Flux und liefern eine reaktive Brücke zwischen LLM-Inference und HTTP-Client. Wer also glaubte, reaktive Programmierung habe ihren Zenit überschritten, findet sich plötzlich in einer Welt wieder, in der jede KI-Anwendung mit Streaming-Anforderungen unweigerlich zur reaktiven Programmierung greift – nicht aus Nostalgie, sondern aus schlichter Notwendigkeit. Der Flux ist das natürliche Gefäß für den Gedankenstrom einer Maschine.
Doch genau hier liegt die eigentliche Nachricht dieses Heftes, und sie bedarf keiner Relativierung: Reactive Streams sterben nicht – sie spezialisieren sich. Dort, wo echte Datenströme fließen – Echtzeit-Streaming, WebSockets unter Extremlast, komplexe Event-Driven Architectures mit Kafka als pulsendem Herzschlag –, dort entfaltet WebFlux seine volle Kraft. Backpressure gehört nicht zum Standardrepertoire von Virtual Threads. Wer Produzenten und Konsumenten in einem dynamischen Gleichgewicht hält, wer Datenströme kontrolliert drosselt, um sie zu beschleunigen, der braucht das reaktive Paradigma – nicht als Notlösung, sondern als bewusste, architektonische Entscheidung eines Teams, das sein Handwerk kennt. Reactive Streams und Virtual Threads schließen sich nicht aus – sie ergänzen sich.
Die reifste Antwort auf die Frage „WebFlux oder Virtual Threads?“ lautet daher weder „WebFlux“ noch „Virtual Threads“. Sie lautet: „Kommt drauf an – und wer das nicht sagt, hat die Frage nicht verstanden.“ Die besten Architekturen entstehen nicht aus Paradigmentreue, sondern aus dem Mut, Werkzeuge situativ einzusetzen. Reaktiv dort, wo Ströme fließen müssen. Imperativ dort, wo Einfachheit Trumpf ist. Hybrid dort, wo die Realität – wie so oft – komplizierter ist als jedes Lehrbuch.
In diesem Sinne halten Sie das vorliegende Heft in Händen beziehungsweise auf dem Bildschirm, denn auch das Lesen hat längst einen asynchronen Charakter angenommen. Die Beiträge, die wir für Sie zusammengestellt haben, beleuchten die Reactive-Landschaft mit dem nötigen Tiefgang und der ehrlichen Auseinandersetzung mit ihren Grenzen. Denn das Klügste, was man über ein mächtiges Paradigma sagen kann, ist nicht nur, was es kann – sondern auch, wann man es besser in der Schublade lässt.
Viel Spaß beim Lesen dieser neuen Ausgabe.
Ihr Prof. Dr. Michael Stal
