TL;DR: Este artigo analisa as novidades do Change Streams no Azure DocumentDB (Public Preview): eventos mais ricos com update descriptions e pre-images, replay histórico para backfill e recuperação, e suporte a múltiplos shards (Multi-Node). Para empresas brasileiras que utilizam MongoDB, essas capacidades eliminam workarounds e viabilizam arquiteturas event-driven mais robustas, com ressalvas de ordenação por shard key e comportamento em failover durante a preview.
Aplicações orientadas a eventos em tempo real deixaram de ser exceção – são o padrão esperado. Times querem dashboards que atualizam no instante em que algo acontece, microservices que reagem assim que um dado chega, e pipelines que movem mudanças para sistemas downstream sem precisar consultar o banco em polling. Desde que Change Streams atingiu General Availability (GA) no Azure DocumentDB, esse padrão se tornou production-ready – e o recurso não parou de evoluir.
Aqui está um resumo do que há de novo desde o GA, com destaque para três capacidades mais pedidas: eventos mais ricos (richer change events), replay histórico (historical replay) e Multi-Node Change Streams, agora em Public Preview.
A ideia em uma imagem
Change streams transformam seu banco de dados em uma fonte de eventos. Um produtor escreve dados, o banco publica cada mudança, e um ou mais consumidores se inscrevem com uma única chamada watch() e reagem em tempo real – sem polling.
O consumidor faz duas coisas: processa cada evento e persiste um resume token, para retomar exatamente de onde parou após restart, deploy ou scale event – sem perder mudanças.
Começar é literalmente uma linha:
const changeStream = db.exampleCollection.watch();
for (const change of changeStream) {
processEvent(change); // cada evento carrega operationType, fullDocument, ns e resume token
}
O que mudou desde o GA?
Eventos mais ricos: update descriptions e pre-images
Os change events agora entregam mais informações sobre o que mudou, não apenas o estado final. Update descriptions expõem exatamente quais campos foram adicionados, removidos ou modificados – ideal para pipelines de change-data-capture (CDC) e auditoria que só querem propagar deltas. Já as pre-images permitem que um evento inclua o documento completo como era antes da alteração, respondendo "qual era o valor antigo?" sem uma consulta extra ao banco.
Pre-images são opt-in por coleção e vêm com modos flexíveis (include-if-available vs. strictly required), já que capturar a versão anterior de cada documento adiciona overhead de armazenamento e processamento. A documentação oficial detalha os modos e os trade-offs.
Historical Change Streams: replay do passado
Change streams padrão vivem dentro de um log ativo – quando ele rotaciona, eventos antigos ficam inacessíveis. Historical Change Streams removem esse teto: você pode reproduzir ou retomar a partir de um ponto no passado, com integração com point-in-time-restore que estende o recovery para aproximadamente o último mês de atividade. Isso é um grande avanço para fazer backfill em um novo sistema downstream, recuperar um consumidor que ficou para trás, ou reprocessar após a correção de um bug.
Compatibilidade ampliada de drivers
Change streams usam a API watch() padrão – nenhum SDK especial ou biblioteca proprietária. O repositório de compatibilidade de drivers contém exemplos executáveis em seis linguagens, todos seguindo o mesmo padrão resiliente: resume se um token existir, senão começa do zero, e persiste o token após cada evento processado.
| Language | Driver |
|---|---|
| Python | PyMongo |
| Java | MongoDB Java Driver |
| Node.js | Mongoose |
| C# | MongoDB .NET Driver |
| Go | MongoDB Go Driver |
| Ruby | MongoDB Ruby Driver |
O padrão é o mesmo em todas as linguagens. Exemplo em Python:
resume_token = load_resume_token()
stream = collection.watch(resume_after=resume_token) if resume_token else collection.watch()
with stream:
for change in stream:
process(change)
save_resume_token(change["_id"]) # persiste após cada evento
Integração com Kafka via conector Debezium
Para arquiteturas event-driven maiores, os change events podem ser enviados diretamente para tópicos Apache Kafka através do conector Debezium, transformando seu banco em uma fonte de eventos de primeira classe para pipelines distribuídos – sem código glue personalizado. Um sample app de delivery-tracking mostra o fluxo completo.
Pipelines de eventos customizáveis
Você pode moldar o feed de cada consumidor passando aggregation stages para watch(). Filtrar apenas as operações e campos que interessam mantém os payloads enxutos e os consumidores focados.
const stream = db.exampleCollection.watch([
{ $match: { operationType: "insert", "fullDocument.department": "IT" } },
{ $project: { "fullDocument.name": 1, "fullDocument.position": 1 } }
]);
Multi-Node Change Streams (Public Preview)
Até recentemente, change streams eram suportados apenas em clusters single-shard, deixando os deployments de maior throughput sem captura de mudanças em tempo real – a menos que engenhassem workarounds. É essa lacuna que o Multi-Node Change Streams fecha, agora em Public Preview.
Conforme seus dados crescem, você escala horizontalmente através de múltiplos shards. Multi-Node Change Streams permite capturar mudanças nessa topologia sharded e multi-node mantendo o mesmo modelo de programação watch() – o código do consumidor, o handling de resume token e o suporte de drivers permanecem idênticos. Apenas a topologia subjacente muda.
Alguns pontos para projetar durante a preview:
- Ordenação é garantida por shard key, não globalmente no cluster.
- A transição do cluster de single-shard para multi-shard afeta a resumabilidade.
- Cursors reiniciam após um failover (a capacidade de resume é preservada).
Por ser uma preview, é o momento ideal para validar com seus workloads em non-production, exercitar o resume e o failover em uma topologia multi-node, e compartilhar feedback que moldará o caminho para o GA.
Comece hoje
Com este release, Change Streams está pronto para workloads de produção. Explore todo o potencial do recurso através da documentação oficial.
Estamos animados para ver o que você construirá com o Azure DocumentDB e Change Streams!
Sobre o Azure DocumentDB
O Azure DocumentDB é um serviço de banco de dados documental totalmente gerenciado para construir e modernizar aplicações compatíveis com MongoDB. Alimentado pelo motor open-source DocumentDB, ele combina APIs, ferramentas e workflows familiares com a segurança, escalabilidade e simplicidade operacional do Azure. Seja para desenvolver novas aplicações ou migrar workloads MongoDB existentes, o Azure DocumentDB ajuda você a começar rapidamente e escalar com confiança.
Perguntas Frequentes
-
O que são pre-images e quando devo habilitá-las?
Pre-images são a versão completa do documento antes da alteração, capturadas opcionalmente por coleção. Devem ser habilitadas quando sua pipeline precisa saber o valor anterior de um campo (auditoria, CDC) sem fazer uma consulta adicional. O custo é o consumo extra de armazenamento e processamento. -
Como funciona o replay histórico em Change Streams?
Historical Change Streams permitem reprocessar eventos de um ponto anterior no tempo, integrado com point-in-time-restore (aproximadamente 30 dias de atividade). É ideal para backfill de novos sistemas downstream, recuperação de consumidores atrasados ou reprocessamento após correção de bugs. -
Quais as limitações do Multi-Node Change Streams durante a preview?
A ordenação é garantida por shard key, não global. A transição de single-shard para multi-shard afeta a resumabilidade. Cursors reiniciam após failover (mas o resume token preserva o progresso). Recomenda-se validar em non-production e testar cenários de failover e resume. -
Preciso alterar meu código para usar as novas funcionalidades?
Não. A API watch() permanece idêntica. Richer events e historical replay são controlados por configuração na coleção (pre-images) e parâmetros da chamada. O suporte multi-node é transparente para o consumidor. Apenas a topologia subjacente muda. -
Como integrar Change Streams com Kafka?
Utilize o conector Debezium para MongoDB, que agora é compatível com Azure DocumentDB. Ele transforma cada change event em uma mensagem Kafka, permitindo pipelines distribuídos sem código glue. A Microsoft disponibiliza um sample app de delivery-tracking para demonstrar o fluxo completo.
Artigo originalmente publicado por Avijit Gupta em Azure Updates - Latest from Azure Charts.
