Quando utilizar Hazelcast

Objetivos

Nesta aula você vai:

Usar um framework de decisão para avaliar Hazelcast em projetos reais
Identificar sinais de que Hazelcast é a escolha errada
Comparar Hazelcast com alternativas do módulo e do mercado

Introdução

Escolher tecnologia é exercício de crítica literária aplicada à engenharia: não basta admirar a prosa — pergunta-se se a obra responde à pergunta que você fez. Hazelcast escreve epopeias distribuídas em Java; Redis escreve haicais de cache universal. Ambos são belos. Nem todo problema pede epopeia.

Esta aula fecha o arco do curso Hazelcast com o veredito do crítico: quando aplaudir de pé, quando reservar ingresso para outra peça.

Conteúdo

Sinais verdes — Hazelcast é candidato forte

Sinal	Por quê Hazelcast
Stack predominantemente Java/Kotlin	Integração nativa, embedded, Spring
Necessidade de locks, semáforos, filas distribuídas	Estruturas prontas, sem reinventar
Computação nos dados (agregações, incrementos atômicos)	Entry processors, Jet
Sessões de usuário com replicação automática	IMap com backup e TTL
Microserviços Java que precisam estado compartilhado	Cluster sem servidor Redis separado
Latência crítica entre serviços Java no mesmo data center	Near Cache, data locality

Caso ilustrativo: plataforma de e-commerce Java com 12 microserviços que compartilham carrinho, estoque reservado e locks de pagamento. Hazelcast centraliza coordenação sem proliferar chamadas HTTP entre serviços.

Sinais vermelhos — reconsidere

Sinal	Alternativa mais simples
Stack políglota (Go, Python, Rust) sem JVM	Redis / DragonflyDB
Cache simples GET/SET entre linguagens	Redis
Equipe pequena sem experiência em clusters JVM	Redis managed (ElastiCache)
Dataset que cabe em Redis sem computação complexa	Redis
Requisito de SQL ad-hoc sobre dados em memória	Apache Ignite
Persistência durável como fonte de verdade	Banco relacional + cache

Anti-padrão clássico: usar Hazelcast embedded em 50 microserviços, cada um formando cluster — 50 clusters distintos ou um mega-cluster instável. Embedded exige disciplina: poucos clusters bem definidos ou modo cliente-servidor com cluster dedicado.

Comparativo de decisão

Critério	Hazelcast	Redis	Apache Ignite
Foco	Data grid + streaming Java	Cache universal	Cache + SQL + persistência
Poliglotismo	Moderado (Java-first)	Excelente	Moderado (Java-first)
Complexidade operacional	Alta (JVM clustering)	Baixa–média	Alta
SQL em memória	Limitado (Jet SQL)	Não (módulos)	Robusto
Computação distribuída	Entry processors, Jet	Lua	Compute grid
Managed cloud	Hazelcast Cloud	ElastiCache, Memorystore	GridGain Cloud

Modelos de deploy recomendados

1. Cluster dedicado + clientes

[Hazelcast Cluster: 3 nós dedicados]
         ▲
    ┌────┴────┬────────┐
  App 1    App 2    App 3  (Hazelcast clients)

Isola ciclo de vida JVM da aplicação
Facilita upgrade e monitoramento
Padrão preferido em produção madura

2. Embedded em aplicação stateful

[App 1 + Hazelcast embedded] ◄──► [App 2 + Hazelcast embedded]

Menos infraestrutura
Risco: deploy da app afeta cluster
Adequado a protótipos ou apps com ciclo de vida alinhado

Checklist de decisão (15 minutos)

Responda sim/não:

Mais de 60% do código relevante é Java? ___
Preciso de estruturas além de chave-valor (filas, locks)? ___
Entry processors ou stream processing são necessários? ___
Tenho equipe para operar cluster JVM (heap, GC, split-brain)? ___
Redis não resolve por limitação técnica comprovada, não por preferência? ___

4–5 sim: Hazelcast merece POC de 2 semanas
2–3 sim: Avalie Redis + biblioteca de coordenação (ex.: Redisson)
0–1 sim: Redis ou cache managed provavelmente bastam

Integração Spring — quando faz sentido

@Cacheable("produtos")
public Produto buscarPorId(String id) { ... }

Spring Cache + Hazelcast funciona, mas trate como cache de segundo nível, não como substituto de banco. Configure TTL e invalidação explícita — cache sem estratégia de invalidação é romance sem desfecho.

Custo total de propriedade

Considere além de licença:

Memória JVM — heap do cluster + heap das apps embedded
Treinamento — particionamento, split-brain, WAN replication
Observabilidade — métricas de cluster, slow operations, near cache hit rate
Upgrade — compatibilidade de serialização entre versões

Hazelcast open source não cobra licença; cobra complexidade. Enterprise cobra ambos — com suporte que pode valer a pena.

Resumo

Hazelcast brilha em ecossistemas Java com necessidade de data grid, coordenação e computação nos dados
Stacks políglotas, caches simples e equipes sem experiência JVM favorecem Redis ou soluções managed
Deploy com cluster dedicado + clientes reduz risco versus embedded em cada microserviço
Use o checklist objetivo antes de POC — preferência tecnológica não substitui requisito comprovado
Compare TCO incluindo operação de cluster, não apenas benchmark de latência