DEV Community: Fabio Rocha

Virtual Threads – adeus, `OutOfMemoryError`; olá, milhões de threads

Fabio Rocha — Wed, 10 Jun 2026 16:38:02 +0000

E aí, dev que vive de ExecutorServicee CompletableFuture? Já tentou criar 10 mil threads na mão? O OutOfMemoryError vem cantando. Isso porque as threads clássicas do Java (agora chamadas de platform threads) são, basicamente, wrappers finos de threads do sistema operacional. Elas são caras – cada uma consome cerca de 20 MB de memória só de pilha (stack).

Mas a partir do JDK 21, temos as virtual threads – leves, baratas. Vamos entender sem mistério.

⚠️ Qual é o problema das Platform Threads (as de sempre)?

Uma thread de plataforma = uma thread do SO.

Isso é caro em tempo (criação lenta) e espaço (stack enorme: ~20 MB).

O escalonador do SO também tem trabalho para trocar o contexto entre elas.

Faça as contas: numa máquina com 8 GB de RAM, cabem no máximo umas 400 threads (8.000 MB / 20 MB = 400). Se essas threads ficarem a maior parte do tempo esperando I/O (como acesso a banco, chamadas HTTP), o CPU fica ocioso – você mal usa o hardware.

Exemplo: uma thread trabalha 0,001 ms preparando um request, depois espera 100 ms pela resposta da rede. Nesse cenário, ela fica parada 99,99% do tempo. Com 400 threads, o uso de CPU é menor que 1%. Um desperdício.

A solução tradicional? Usar pools de threads, CompletableFuture, programação reativa (Mono/Flux). Mas o código fica mais complexo, cheio de callbacks.

✨ Virtual Threads – a revolução

Virtual threads são leves – cada uma ocupa poucos bytes (não megabytes) e vivem no heap da JVM, não na pilha do SO. Criar uma virtual thread é ~1000 vezes mais barato que uma platform thread. Elas são gerenciadas pelo próprio JVM, não pelo escalonador do SO.

A arquitetura é de muitos para poucos: milhões de virtual threads rodam em cima de um pequeno número de platform threads (as velhas conhecidas). Cada platform thread executa uma virtual thread por vez, e quando a virtual thread bloqueia (ex: aguardando I/O), a JVM desmonta ela dali e a platform thread pega outra virtual thread pronta. Isso chama-se escalonamento cooperativo – ninguém fica parado.

📌 Nota importante:

Virtual threads não devem ser pooladas nem reutilizadas. São descartáveis, baratas, criamos uma para cada tarefa concorrente e pronto.

🛠️ Criando e usando virtual threads na prática

Vamos pegar uma tarefa simples:

Runnable task = () -> System.out.println(
    Thread.currentThread().toString());

1. Criar e já iniciar com `startVirtualThread()`

Thread vThread = Thread.startVirtualThread(task);
vThread.setName("minhaVirtual");

2. Usando `Thread.ofVirtual()`

Thread vThread = Thread.ofVirtual().start(task);
// Com nome
Thread vThread = Thread.ofVirtual().name("minhaVirtual").start(task);

3. Usando `Thread.Builder` (útil para várias)

Thread.Builder builder = Thread.ofVirtual().name("vt-", 1);
Thread t1 = builder.start(task);
t1.join();
Thread t2 = builder.start(task);
t2.join();

4. Criar sem iniciar (`unstarted`)

Thread vThread = Thread.ofVirtual().unstarted(task);
// depois...
vThread.start();

5. `ThreadFactory` de virtual threads

ThreadFactory factory = Thread.ofVirtual().name("worker-").factory();
Thread vThread = factory.newThread(task);
vThread.start();

Fácil, né? Você usa a mesma API java.lang.Thread que já conhece. Não precisa aprender CompletableFuture ou reactive streams – o código fica sequencial e legível.

🔍 Detalhes que você precisa saber

isVirtual() → retorna true.
É daemon por padrão (isDaemon() = true). Não tente mudar.
Prioridade sempre NORM_PRIORITY (5). setPriority() não tem efeito.
Não pertence a ThreadGroup tradicional – o grupo se chama "VirtualThreads".
toString() mostra algo como: VirtualThread[#22]/runnable@ForkJoinPool-1-worker-1. O ForkJoinPool-1-worker-1 é a carrier thread (platform thread) que está executando sua virtual thread.

🚀 Quantas virtual threads conseguimos criar?

Rode isso (com cuidado, porque ele trava o sistema só depois de milhões):

AtomicLong contador = new AtomicLong();
while (true) {
    Thread.startVirtualThread(() -> {
        long id = contador.incrementAndGet();
        System.out.println("Virtual thread: " + id);
        LockSupport.park(); // trava a thread virtual
    });
}

No meu notebook, depois de 14 milhões de virtual threads o sistema ficou lento (GC atuando forte), mas não estourou memória. Isso é outro patamar de concorrência.

❗ Mitos que você deve esquecer

"Virtual threads são mais rápidas" – ERRADO. Elas não tornam código computacional mais rápido. Para CPU pesado, use parallel streams. Virtual threads melhoram throughput (você pode ter milhões esperando I/O), mas não latência.
"Devemos poolá-las" – ERRADO. Nunca crie um pool de virtual threads. Elas são descartáveis, baratas. Cada tarefa ganha a sua.
"Virtual threads são gratuitas" – ERRADO. Não são de graça, mas são 1000x mais baratas que platform threads.
"Se bloquear a virtual thread, a carrier thread também trava" – ERRADO. A JVM desmonta a virtual thread bloqueada e a carrier thread pega outra. O bloqueio não afeta outras virtual threads.

🔄 Compatibilidade retrógrada

Virtual threads funcionam com:

Blocos synchronized
ThreadLocal (mas cuidado com o número excessivo – pode não escalar)
Thread.currentThread()
interrupt() e InterruptedException

Ou seja, seu código antigo simplesmente roda em virtual threads – sem modificação. Basta mudar de new Thread(...).start() para Thread.startVirtualThread(...).

📌 Quando usar (e quando não usar)

✅ Ótimo para:

Muitas tarefas de I/O (chamadas HTTP, leitura de banco, acesso a arquivos)
Servidores web com alta concorrência
Substituir CompletableFuture e código reativo cheio de callbacks

❌ Não tão útil para:

Processamento intensivo de CPU (cálculos, criptografia, compressão) – prefira parallel streams ou manter pool de platform threads com tamanho = número de cores

🧠 Exemplo prático: simulando 10.000 chamadas HTTP

Com virtual threads fica limpo:

var httpClient = HttpClient.newHttpClient();
var requests = IntStream.range(0, 10_000)
    .mapToObj(i -> HttpRequest.newBuilder(URI.create("https://api.exemplo.com/users/" + i)).build())
    .toList();

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    var futures = requests.stream()
        .map(req -> executor.submit(() -> httpClient.send(req, BodyHandlers.ofString())))
        .toList();

    for (var future : futures) {
        var response = future.get();
        System.out.println(response.body().length());
    }
}

Criamos 10.000 virtual threads ao mesmo tempo, cada uma esperando I/O. Com platform threads, isso seria impossível sem um pool enorme e OutOfMemoryError. Com virtual threads, roda liso.

🎯 Conclusão

Virtual threads são um divisor de águas para concorrência em Java:

✔️ Crie milhões delas sem medo
✔️ Código simples e bloqueante (nada de callbacks)
✔️ Aproveite ao máximo o hardware em tarefas de I/O
✔️ Compatível com todo o ecossistema Java

Então da próxima vez que pensar em CompletableFuture ou reactive streams, pergunte-se: dá pra resolver com virtual threads? Muitas vezes, a resposta é sim – com muito menos neuras.

Gostou? Testa aí no seu código com JDK 21+ e me conta o que achou. E lembre-se: thread virtual não é mais rápida, mas você pode ter tantas que parece mágica. ✨

Java21 #VirtualThreads #Concorrência #ProgramaçãoAssíncrona #JDK

Quer mais? O próximo post vai mostrar como usar virtual threads com Spring Boot e comparar performance com reactive. Até lá!

Kafka sem duplicação – 2 padrões pra você dormir em paz

Fabio Rocha — Wed, 27 May 2026 19:57:38 +0000

🔁 Kafka sem duplicação – 3 padrões? Não, 2 bastam! (os que realmente funcionam)

E aí, pessoa desenvolvedora de microsserviços? Já teve pesadelo com mensagem duplicada no Kafka? Já processou o mesmo evento duas vezes e olhou pro banco de dados com aquele suor frio descendo a espinha? Pois é. Duplicação é a pedra no sapato de qualquer sistema distribuído.

Mas calma. Hoje a gente vai focar nos dois padrões que realmente resolvem o problema sem firula: Consumidor Idempotente e Transactional Outbox. Nada de Kafka Transaction API (que, entre nós, mais atrapalha do que ajuda quando tem banco relacional no meio). Pega um café, bora codar com menos susto e mais confiança! 🚀

O cenário clássico que dá pesadelo

Imagine que seu serviço consome uma mensagem de um tópico, faz o seguinte pipeline:

🔁 Faz um POST em uma API externa
💾 Insere um registro no banco de dados
📤 Publica um evento em um tópico de saída

Seu código consome a mensagem, processa e só depois de tudo isso commit do offset no Kafka.

Aí o sistema morre bem no meio. O que acontece? A mensagem ainda não foi marcada como consumida. Kafka acha que o consumidor morreu e rebalanceia a partição para outra instância, que vai pegar exatamente a mesma mensagem e processar de novo. Resultado: POST duplicado, INSERT duplicado, evento duplicado. E você na UTI do sistema às 3 da manhã. ☠️

Mas calma, que temos dois padrões matadores para resolver isso. Bora?

🔑 Padrão 1: Consumidor Idempotente

A ideia aqui é simples: seu consumidor pode receber a mesma mensagem várias vezes, mas só processa uma vez por meio de IDs únicos armazenados.

Como funciona na prática:

1. ID único (Idempotency Key): Sua mensagem precisa carregar um identificador único, tipo transactionId ou eventId. Esse ID pode vir no header do Kafka ou dentro do payload.

2. Tabela de mensagens processadas: No mesmo banco onde você faz as escritas do seu negócio, cria uma tabelinha "processed_messages" com a chave primária sendo esse ID.

3. Processamento atômico: Você insere o ID nessa tabela na mesma transação que as outras escritas do banco. Se der pau no meio, tudo rola junto!

@Transactional
public void processarEvento(ConsumerRecord<String, OrderEvent> record) {
    String eventId = record.headers().lastHeader("eventId");

    // Se já existe, é duplicata
    if (processedMessageRepo.existsById(eventId)) {
        log.info("📌 Evento {} já processado. Pulando!", eventId);
        return;
    }

    // Processa o negócio
    orderService.criarPedido(record.value());

    // Marca como processado na MESMA transação
    processedMessageRepo.save(new ProcessedMessage(eventId));
}

Se criarPedido falhar, a inserção na tabela processed_messages também rola de volta automaticamente. O @Transactional garante a atomicidade.

Vantagem: Simples, funciona com qualquer banco relacional.

Desvantagem: Não resolve sozinho a publicação atômica de eventos no Kafka (pra isso entra o padrão 2).

📦 Padrão 2: Transactional Outbox

Esse padrão resolve um outro problema clássico: você precisa publicar um evento no Kafka e gravar no banco de dados, mas as duas ações não podem ser atômicas usando o mesmo contexto transacional.

A solução é:

Tabela Outbox: Em vez de publicar direto no Kafka, você insere o evento em uma tabela outbox na mesma transação que suas escritas de negócio.
CDC (Change Data Capture): Ferramentas como Debezium monitoram a tabela outbox e publicam os eventos no tópico final de forma garantida e idempotente.

BEGIN;
  -- 1. Escrita de negócio
  INSERT INTO pedidos (id, valor, cliente_id) VALUES (123, 100.00, 1);

  -- 2. Evento vai pra tabela outbox (na mesma transação!)
  INSERT INTO outbox (aggregate_id, event_type, payload)
  VALUES (123, 'PedidoCriado', '{"valor": 100.00}');
COMMIT;

Com CDC, o evento vai parar no tópico final sem risco de inconsistência entre banco de dados e Kafka.

Vantagem: Publicação confiável e atômica com o banco.

Desvantagem: Requer infra adicional (Debezium, Kafka Connect), e o CDC pode ter latência de segundos.

👑 O combo campeão: consumidor idempotente + outbox

Agora junta os dois: o padrão 1 garante que a mesma mensagem não vai ser processada duas vezes no consumidor, e o padrão 2 garante que os eventos de saída serão publicados de forma confiável sem duplicação no lado do produtor.

Juntos, eles formam a base de qualquer microsserviço que se preze:

@Transactional
public void processarEventoIntegrado(ConsumerRecord<String, Evento> record) {
    // 1. Idempotent Consumer: verifica se já processou
    String eventId = record.headers().lastHeader("eventId");
    if (processedMessageRepo.existsById(eventId)) {
        return;
    }

    // 2. Chama API externa (não tem jeito, aqui pode dar duplicata)
    //    Mas aí é problema da API externa ser idempotente, não nosso :)
    apiExterna.criarRecurso(record.value().getDados());

    // 3. Escrita de negócio + outbox (tudo na mesma transação)
    pedidoService.criarPedido(record.value().getPedido());
    outboxRepo.save(criarEventoOutbox(record.value()));

    // 4. Marca como processado (ainda na mesma transação)
    processedMessageRepo.save(new ProcessedMessage(eventId));
}

Pronto. Você dorme em paz.

⚠️ Melhores práticas e dicas quentes que ninguém conta

1.🔑 Idempotency Keys bem feitas

UUID gerado no cliente: Mais seguro. O produtor gera, e o ID viaja até o consumidor.
Chave composta de negócio: Exemplo: customerId:orderId:timestamp. Funciona se a combinação for verdadeiramente única.
Coordenadas do Kafka: Usar topic-partition-offset como ID. Simples, mas quebra se você reproduzir o evento a partir de um tópico diferente.

2.⏱️ Cuidado com timeouts e rebalanceamento

Configuração max.poll.interval.ms e max.poll.records precisa estar alinhada com o tempo médio de processamento do seu lote. Se o consumidor demorar demais e não conseguir chamar poll() dentro do tempo, o broker acha que ele morreu e redistribui as partições – causando reprocessamento.

3.🧹 Limpeza da tabela `processed_messages`

Essa tabela pode crescer infinitamente. Crie uma rotina de limpeza assíncrona (ex: job diário que apaga registros com mais de 7 dias).

4.🧪 Outbox com polling simples (sem CDC)

Se você não quiser usar Debezium, pode implementar um polling publisher – um scheduler que lê da tabela outbox e publica no Kafka em lotes. Mas aí você assume responsabilidade de idempotência e transação.

5.🚫 O que não fazer

Não tente coordenar transações entre Kafka e banco com XA ou JTA. É lento, frágil e geralmente um pesadelo.
Não use Kafka Transaction API junto com transações de banco. Já vimos que a combinação não é atômica e pode causar perda de dados.

🧭 Fluxo de decisão: qual padrão escolher?

Você só precisa gravar no banco e ponto?
  ├─ Banco relacional → Idempotent Consumer com tabela processed_messages
  └─ NoSQL (Redis, MongoDB) → Use lock distribuído (SETNX) ou tabela auxiliar

Você precisa gravar no banco E publicar eventos no Kafka:
  ├─ Tem budget e infra para CDC (Debezium)? → Transactional Outbox + Idempotent Consumer (recomendado)
  ├─ Quer algo mais leve sem CDC? → Outbox com polling + Idempotent Consumer
  └─ Precisa de latência baixíssima (milissegundos)? → Idempotent Consumer + transação manual com idempotent producer (cuidado!)

Cenário ideal para microsserviços críticos:
  ✅ Idempotent Consumer + Transactional Outbox (com CDC)

💬 Dúvida comum: por que não usar Kafka Transaction API?

Essa pergunta aparece muito. A resposta direta: Kafka Transaction API foi feita para cenários de stream processing onde a única fonte de verdade é o próprio Kafka (ex: Kafka Streams). Quando você tem um banco relacional no meio, tentar unir as duas transações não traz atomicidade real e ainda introduz complexidade sem necessidade.

Os padrões 1 e 2 resolvem o problema de forma comprovada, com ferramentas maduras (Debezium, PostgreSQL, etc.) e sem surpresas. Por que inventar moda? 😎

🎯 Conclusão

Duplicação de mensagem não é questão de "se" vai acontecer, mas de "quando". As garantias de "at-most-once" e "at-least-once" do Kafka são otimistas demais para sistemas reais. O que salva é o design idempotente do seu consumidor.

Lembre-se:

A base de tudo é o Idempotent Consumer (eventId + tabela de controle)
O Transactional Outbox garante a publicação confiável de eventos sem duas fases de commit
O combo Idempotent Consumer + Outbox é o mais recomendado, robusto e dorme-se em paz
Esqueça Kafka Transaction API se você tem banco de dados – não é pra você

Agora é sua vez: já passou por algum apagão de duplicação? Me conta nos comentários como resolveu. E se ainda não passou, já sabe onde mirar quando o caos chegar. Bora codar com menos duplicata e mais paz de espírito! 🛡️🔥

Quer mais conteúdo sobre Kafka, arquitetura de microsserviços e resiliência? Segue o blog e ativa as notificações – o próximo post vai ser sobre "Dead Letter Queues e como não perder eventos". Não perde!

Trabalhando com mapMulti() – Transforme seus streams sem neuras

Fabio Rocha — Wed, 20 May 2026 18:17:18 +0000

Trabalhando com `mapMulti()` – Transforme seus streams sem neuras

E aí, dev? Tudo certo?

Se você está no JDK 16 ou superior, a Stream API ganhou um novo brinquedo: o método mapMulti(). Ele parece meio estranho no começo, mas juro que depois que você entende, começa a usar até pra fazer café ☕.

A ideia é simples: ele permite mapear cada elemento do stream para zero, um ou vários elementos novos, tudo dentro de um único BiConsumer. Chega de ficar encadeando filter() e map() que nem louco? Bom, nem sempre, mas em muitos casos sim. Vamos ver na prática.

🔍 Exemplo clássico vs `mapMulti()`

Imagina que você tem uma lista de notas de alunos e quer filtrar só as notas maiores ou iguais a 7 e aplicar um bônus de 10% em cada uma.

Modo tradicional (filter + map):

List<Double> notas = List.of(5.5, 8.0, 6.0, 9.5, 7.0, 4.0);

List<Double> notasComBonus = notas.stream()
    .filter(n -> n >= 7)
    .map(n -> n * 1.10)
    .collect(Collectors.toList());

// Resultado: [8.8, 10.45, 7.7]

Agora com mapMulti() a gente faz a mesma coisa com uma só operação:

List<Double> notasComBonusMM = notas.stream()
    .<Double>mapMulti((nota, consumer) -> {
        if (nota >= 7) {
            consumer.accept(nota * 1.10);
        }
    })
    .collect(Collectors.toList());

O if faz o papel do filter(), e o accept() aplica o map().

Perceba o .<Double> antes do mapMulti – isso é um type-witness (o compilador chato pediu). Sem ele o código não compila. Um pequeno preço a pagar.

🧮 Trabalhando com tipos primitivos – `mapMultiToDouble()`

Se a sua ideia é somar essas notas com bônus, melhor usar a versão especializada para double:

double somaComBonus = notas.stream()
    .mapMultiToDouble((nota, consumer) -> {
        if (nota >= 7) {
            consumer.accept(nota * 1.10);
        }
    })
    .sum();

System.out.println(somaComBonus); // 26.95

Sem type-witness, sem firula. E se depois você quiser voltar a ter um Stream<Double>, é só usar boxed() ou mapToObj():

Stream<Double> streamBonus = notas.stream()
    .mapMultiToDouble((nota, consumer) -> {
        if (nota >= 7) consumer.accept(nota * 1.10);
    })
    .boxed();

📦 `flatMap()` vs `mapMulti()` – o duelo do one‑to‑many

Vamos para um exemplo mais real. Temos categorias de produtos, e cada categoria tem vários produtos. Queremos gerar uma lista simples de ProdutoInfo contendo o nome da categoria + o nome do produto.

class Categoria {
    private String nome;
    private List<Produto> produtos;
    // getters...
}

class Produto {
    private String nome;
    private double preco;
    // getters...
}

class ProdutoInfo {
    private String categoria;
    private String produto;
    // construtor, getters...
}

Com `flatMap()` (tradicional)

List<ProdutoInfo> listaFlat = categorias.stream()
    .flatMap(cat -> cat.getProdutos().stream()
        .map(prod -> new ProdutoInfo(cat.getNome(), prod.getNome()))
    )
    .collect(Collectors.toList());

O problema aqui é que, para cada categoria, criamos um stream intermediário (o cat.getProdutos().stream()). Se forem muitas categorias, isso pesa.

Com `mapMulti()` (mais enxuto)

List<ProdutoInfo> listaMM = categorias.stream()
    .<ProdutoInfo>mapMulti((categoria, consumer) -> {
        for (Produto p : categoria.getProdutos()) {
            consumer.accept(new ProdutoInfo(categoria.getNome(), p.getNome()));
        }
    })
    .collect(Collectors.toList());

Sem streams intermediários, só um laço for simples. Mais performático e, na minha opinião, mais fácil de ler.

🎯 Com filtro adicional – só produtos acima de R$ 50

Se você quiser só produtos com preço maior que 50, a vantagem do mapMulti() fica ainda mais clara:

List<ProdutoInfo> listaCaros = categorias.stream()
    .<ProdutoInfo>mapMulti((categoria, consumer) -> {
        for (Produto p : categoria.getProdutos()) {
            if (p.getPreco() > 50) {
                consumer.accept(new ProdutoInfo(categoria.getNome(), p.getNome()));
            }
        }
    })
    .collect(Collectors.toList());

Aqui você evita um filter() extra e mantém tudo no mesmo lugar. E repara: cada categoria tem poucos produtos (geralmente), então se encaixa perfeitamente na recomendação oficial:

Use mapMulti() quando for substituir cada elemento do stream por um pequeno número (possivelmente zero) de elementos.

🧠 Abordagem imperativa? Também vale!

Sabe aquele método que já faz a lógica toda e recebe um Consumer? Então... você pode passar ele direto pro mapMulti().

Adicione na classe Categoria:

public void produtosCaros(Consumer<ProdutoInfo> consumer, double limite) {
    for (Produto p : this.produtos) {
        if (p.getPreco() > limite) {
            consumer.accept(new ProdutoInfo(this.nome, p.getNome()));
        }
    }
}

Agora seu stream fica limpo igual água de coco:

List<ProdutoInfo> resultado = categorias.stream()
    .<ProdutoInfo>mapMulti(cat -> cat.produtosCaros(consumer, 50))
    .collect(Collectors.toList());

Ou usando method reference (ainda mais lindo):

.<ProdutoInfo>mapMulti(cat -> cat.produtosCaros(consumer, 50))
// ou, se o limite for fixo:
.<ProdutoInfo>mapMulti(cat -> cat.produtosCaros(consumer, 50))

(Na real com method reference você teria que adaptar, mas a ideia é que o mapMulti aceita um lambda que chama seu método imperativo.)

✅ Quando usar `mapMulti()` – resumo da ópera

Você tem uma relação one‑to‑zero/one‑to‑many e o número de elementos gerados por elemento original é pequeno.
Quer evitar criar streams intermediários (melhor performance em laços grandes).
O código fica mais claro com um laço for e if do que com flatMap + filter + map.
Você já tem um método que recebe Consumer e quer integrar direto no stream.

O mapMulti() não vai matar o flatMap() – cada um tem seu lugar. Mas quando o cenário se encaixa, é como trocar uma chave de fenda por uma chave Philips: faz o mesmo serviço, mas com muito mais estilo.

Gostou? Testa aí no seu código e me conta se os streams ficaram mais limpos. Até a próxima, e bora codar com menos firula e mais resultado! 🚀

DEV Community: Fabio Rocha

Virtual Threads – adeus, `OutOfMemoryError`; olá, milhões de threads

⚠️ Qual é o problema das Platform Threads (as de sempre)?

✨ Virtual Threads – a revolução

🛠️ Criando e usando virtual threads na prática

1. Criar e já iniciar com startVirtualThread()

2. Usando Thread.ofVirtual()

3. Usando Thread.Builder (útil para várias)

4. Criar sem iniciar (unstarted)

5. ThreadFactory de virtual threads

🔍 Detalhes que você precisa saber

🚀 Quantas virtual threads conseguimos criar?

❗ Mitos que você deve esquecer

🔄 Compatibilidade retrógrada

📌 Quando usar (e quando não usar)

✅ Ótimo para:

❌ Não tão útil para:

🧠 Exemplo prático: simulando 10.000 chamadas HTTP

🎯 Conclusão

Java21 #VirtualThreads #Concorrência #ProgramaçãoAssíncrona #JDK

Kafka sem duplicação – 2 padrões pra você dormir em paz

🔁 Kafka sem duplicação – 3 padrões? Não, 2 bastam! (os que realmente funcionam)

O cenário clássico que dá pesadelo

🔑 Padrão 1: Consumidor Idempotente

Como funciona na prática:

📦 Padrão 2: Transactional Outbox

👑 O combo campeão: consumidor idempotente + outbox

⚠️ Melhores práticas e dicas quentes que ninguém conta

1.🔑 Idempotency Keys bem feitas

2.⏱️ Cuidado com timeouts e rebalanceamento

3.🧹 Limpeza da tabela processed_messages

4.🧪 Outbox com polling simples (sem CDC)

5.🚫 O que não fazer

🧭 Fluxo de decisão: qual padrão escolher?

💬 Dúvida comum: por que não usar Kafka Transaction API?

🎯 Conclusão

Trabalhando com mapMulti() – Transforme seus streams sem neuras

Trabalhando com mapMulti() – Transforme seus streams sem neuras

🔍 Exemplo clássico vs mapMulti()

🧮 Trabalhando com tipos primitivos – mapMultiToDouble()

📦 flatMap() vs mapMulti() – o duelo do one‑to‑many

Com flatMap() (tradicional)

Com mapMulti() (mais enxuto)

🎯 Com filtro adicional – só produtos acima de R$ 50

🧠 Abordagem imperativa? Também vale!

✅ Quando usar mapMulti() – resumo da ópera

1. Criar e já iniciar com `startVirtualThread()`

2. Usando `Thread.ofVirtual()`

3. Usando `Thread.Builder` (útil para várias)

4. Criar sem iniciar (`unstarted`)

5. `ThreadFactory` de virtual threads

3.🧹 Limpeza da tabela `processed_messages`

Trabalhando com `mapMulti()` – Transforme seus streams sem neuras

🔍 Exemplo clássico vs `mapMulti()`

🧮 Trabalhando com tipos primitivos – `mapMultiToDouble()`

📦 `flatMap()` vs `mapMulti()` – o duelo do one‑to‑many

Com `flatMap()` (tradicional)

Com `mapMulti()` (mais enxuto)

✅ Quando usar `mapMulti()` – resumo da ópera