Programação Reativa

TL;DR

O Galho 11 cobre o modelo reativo na JVM: o que é programação reativa e o Reactive Streams, Mono/Flux e os operadores do Project Reactor, schedulers e backpressure, Spring WebFlux e WebClient, R2DBC, e o confronto honesto reativo vs Virtual Threads — quando usar e, principalmente, quando não usar. São 16 notas em 3 fases (Iniciado, Adepto, Magus).

Sobre este galho

Programação reativa é o modelo push, assíncrono e não-bloqueante da JVM: dados como um stream que empurra eventos a quem reage, sob controle de demanda (backpressure), compostos declarativamente por operadores. Este galho parte do conceito e do Reactive Streams, percorre o Project Reactor (Mono/Flux, operadores, schedulers, backpressure), sobe pra camada web (Spring WebFlux, WebClient, functional endpoints), desce pro banco (R2DBC) e fecha com a decisão de engenharia: quando reativo paga o próprio custo.

Audiência primária: dev pleno/sênior que vai encarar entrevista internacional e precisa explicar o modelo reativo com critério. Secundária: quem mantém ou avalia um stack WebFlux/R2DBC e precisa decidir entre reativo e o imperativo.

É um galho novo (majoritariamente pesquisa em doc oficial — Project Reactor, Spring WebFlux, R2DBC, Reactive Streams), com uma única poda cirúrgica: a seção ## Spring WebFlux do tronco Backend/Spring Boot.md, que apenas apontava “merece sua própria nota”. E tem quádrupla fronteira: este galho confronta o modelo de threads do Galho 4 (Concorrência e paralelismo — o confronto reativo vs Virtual Threads), substitui o stack web do Galho 9 (Web e APIs REST — Spring MVC imperativo vs WebFlux reativo), contrasta a persistência do Galho 10 (Persistência de dados — JPA/JDBC bloqueante vs R2DBC reativo) e roda sobre o container do Galho 8 (Spring Core e Boot). As notas linkam de volta a essas fronteiras sem re-explicá-las.

A tese central, sem hype: os Virtual Threads (Java 21 GA) tornaram o modelo imperativo viável pra alta concorrência I/O-bound sem a complexidade do Reactor — então reativo virou nicho: ainda vence em streaming real e backpressure de verdade, mas perdeu a maioria dos CRUDs. Por isso “quando não usar reativo” é metade do galho.

Mensageria reativa/Reactor Kafka é o galho Mensageria; resiliência/backpressure distribuído é o galho Microservices e sistemas distribuídos e segurança reativa/WebFlux Security é fronteira do galho Segurança; testes reativos com StepVerifier são o galho Testes.

Iniciado

O modelo mental — antes de qualquer operador.

• 01 — O que é programação reativa — push vs pull, não-bloqueante, e por que serve I/O-bound com poucos threads.
• 02 — Reactive Streams — a spec das 4 interfaces (Publisher/Subscriber/Subscription/Processor) e o java.util.concurrent.Flow do Java 9.
• 03 — Mono e Flux — os publishers do Reactor: Mono (0-1) vs Flux (0-N) e a criação.
• 04 — Nada acontece até o subscribe — lazy, assembly vs subscription time, cold vs hot.

Adepto

Operadores, fluxo e a camada web.

• 05 — map e flatMap — a confusão central: transformação síncrona 1:1 vs assíncrona que achata publishers.
• 06 — Combinando publishers — zip, merge, concat, filter e quando a ordem importa.
• 07 — Error handling reativo — o erro como sinal terminal e a recuperação declarativa (onError*, retry).
• 08 — Schedulers — subscribeOn vs publishOn, os Schedulers e nunca bloquear o event loop.
• 09 — Backpressure — o coração do Reactive Streams: request(n) e as estratégias de overflow.
• 10 — Spring WebFlux — o event loop sobre Netty e o DispatcherHandler (vs o DispatcherServlet do Galho 9).
• 11 — WebClient — o cliente HTTP reativo, par do RestClient síncrono do Galho 9.
• 12 — Functional endpoints — a alternativa funcional aos controllers anotados (RouterFunction/HandlerFunction).

Magus

Persistência reativa, o confronto e a decisão.

• 13 — R2DBC — acesso reativo ao banco sem EntityManager, persistence context nem lazy loading (vs a JPA do Galho 10).
• 14 — Reativo vs Virtual Threads — o confronto que o Galho 4 adiou: onde reativo ainda vence e onde os Virtual Threads venceram.
• 15 — Quando (não) usar reativo — o custo cognitivo, os stack traces fragmentados e o checklist de decisão honesto.
• 16 — Capstone — uma request reativa do DispatcherHandler ao Flux, sem bloquear o event loop.

Rotas alternativas

• Completa — 01 → 16 em ordem (o caminho do modelo ao capstone).
• Entrevista internacional — 01 → 03 → 05 → 09 → 10 → 14 → 16 (modelo, Mono/Flux, map/flatMap, backpressure, WebFlux, reativo-vs-VT, capstone — o que mais cai).
• Os operadores do Reactor — 03 → 04 → 05 → 06 → 07 → 08 (Mono/Flux, lazy, map/flatMap, combinação, erro, schedulers).
• O stack web reativo — 01 → 10 → 11 → 12 → 13 → 16 (modelo, WebFlux, WebClient, functional, R2DBC, capstone).
• Reativo vs Virtual Threads (a ponte com o Galho 4) — 01 → 09 → 14 → 15 + Virtual Threads e Project Loom (a decisão honesta).

Todas as notas

TABLE fase AS "Fase", status AS "Status"
FROM "03-Dominios/Java/Programação Reativa"
WHERE type = "concept"
SORT file.name ASC

Veja também

• Trilha Java (MOC central)
• Concorrência e paralelismo — o modelo de threads e o confronto com Virtual Threads (Galho 4)
• Web e APIs REST — o stack web imperativo que o WebFlux substitui (Galho 9)
• Persistência de dados — a JPA/JDBC bloqueante que o R2DBC contrasta (Galho 10)
• Spring Core e Boot — o container e a auto-configuration sob o WebFlux (Galho 8)
• Dicionário de Java — glossário de termos da trilha

Galhos 12 (Segurança), 13 (Testes), 14 (Mensageria), 16 (Microservices) e 17 (Cloud-native) — planejados.