Visão geral das arquiteturas orientadas a eventos com o Eventarc
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Use o Eventarc e o Firestore no modo Datastore para criar arquiteturas orientadas a eventos.
O Firestore no modo Datastore oferece gatilhos para o Eventarc que geram eventos de mudanças em uma entidade específica do banco de dados. O acionador pode rotear eventos para um destino aceito:
O Eventarc oferece uma solução padronizada para gerenciar o fluxo de
mudanças de estado, chamadas de eventos, entre microsserviços separados. Quando acionado,
o Eventarc encaminha esses eventos para
vários destinos, enquanto gerencia a entrega, a segurança, a autorização, a observabilidade e o tratamento de erros para você.
Exemplos de casos de uso
Uma arquitetura orientada a eventos é um padrão de design de sistema em que os serviços reagem
a mudanças no estado, conhecidas como eventos. Você pode usar esse padrão com a
escalonabilidade do Firestore para adicionar mais recursos ao app.
Por exemplo, é possível adicionar os seguintes recursos:
Interoperabilidade entre diferentes pilhas de tecnologia
Replique e transforme seus dados antes de enviá-los para um
sistema de análise.
Processamento paralelo
Distribua as operações para processamento paralelo. Se você tiver vários sistemas que
operam com base em mudanças de entidade, use os streams baseados em push em cada
consumidor e roteie o evento para vários consumidores.
Fluxos de eventos baseados em push
Crie designs de mensagens push. Os clientes podem receber notificações sem precisar consultar serviços remotos. Sem a latência de pesquisa,
é possível realizar melhor o processamento de dados e a análise em tempo real.
Monitoramento e alertas de estado
Use uma arquitetura orientada a eventos para adicionar métricas personalizadas às suas operações de banco de dados. Monitore e receba alertas sobre mudanças e atualizações. Detecte anomalias.
Limitações
Observe as seguintes limitações para gatilhos do modo Datastore para o Eventarc:
Não garantimos acionamentos em ordem. Mudanças rápidas podem acionar eventos em uma ordem inesperada.
Os eventos são entregues pelo menos uma vez.
Confira se o gerenciador de eventos é idempotente e evite produzir resultados inesperados
ou efeitos colaterais quando um evento é enviado mais de uma vez. Consulte Como criar funções idempotentes para saber mais.
Um gatilho está associado a um único banco de dados. Não é possível criar um gatilho que corresponda a vários bancos de dados.
A exclusão de um banco de dados não remove automaticamente nenhum gatilho dele. O
gatilho deixa de entregar eventos, mas continua existindo até que você o exclua.
Eventarc e Firestore nos locais do modo Datastore
O Eventarc não oferece suporte a várias regiões para gatilhos de eventos do Firestore, mas você ainda pode criar gatilhos para bancos de dados do Firestore
em locais multirregionais. O Eventarc mapeia os locais de várias regiões do Firestore para as seguintes regiões do Eventarc:
Multirregião do Firestore
Região do Eventarc
nam5
us-central1
eur3
europe-west4
Interoperabilidade de eventos do modo Datastore e do modo nativo
O Eventarc é compatível com gatilhos de evento para o modo Datastore e o modo
nativo. Esses acionadores de eventos são interoperáveis com os dois tipos de banco de dados.
Um banco de dados do Firestore no modo nativo pode receber eventos do Datastore, e um banco de dados do Firestore no modo Datastore pode receber
eventos do modo nativo.
A interoperabilidade de eventos permite compartilhar o código do Eventarc em
bancos de dados do Firestore de tipos diferentes.
Conversões de eventos
Se você aplicar um gatilho de evento do modo nativo a um banco de dados do modo do Datastore, o Eventarc fará as seguintes conversões:
O namespace da entidade é armazenado no atributo PartitionId do evento.
As entidades incorporadas são convertidas em tipos map do modo nativo.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-03 UTC."],[[["\u003cp\u003eEventarc and Firestore in Datastore mode enable the creation of event-driven architectures by generating events from database entity changes.\u003c/p\u003e\n"],["\u003cp\u003eEventarc routes events triggered by Firestore changes to various destinations, including Cloud Run, Cloud Run functions (2nd gen), Google Kubernetes Engine, and Workflows.\u003c/p\u003e\n"],["\u003cp\u003eEvent-driven architectures with Eventarc and Firestore offer benefits like interoperability, parallel processing, push-based event streams, and state monitoring with custom alerts.\u003c/p\u003e\n"],["\u003cp\u003eLimitations of Datastore mode triggers for Eventarc include non-guaranteed ordering, at-least-once delivery of events, and triggers being tied to a single database.\u003c/p\u003e\n"],["\u003cp\u003eEventarc supports event triggers for both Datastore mode and Native mode in Firestore, allowing interoperability and code sharing between different database types.\u003c/p\u003e\n"]]],[],null,["# Overview of event-driven architectures with Eventarc\n\nYou can use [Eventarc](/eventarc/docs/overview) and\nFirestore in Datastore mode to build\nevent-driven architectures.\nFirestore in Datastore mode provides triggers for\nEventarc that generate events from changes\nto a particular entity in your database. The trigger can route events to a\n[supported destination](/eventarc/docs/event-providers-targets):\n\n- [Cloud Run functions (2nd gen)](/datastore/docs/extend-with-functions-2nd-gen)\n- [Cloud Run](/eventarc/docs/run/route-trigger-cloud-firestore)\n- [Google Kubernetes Engine](/eventarc/docs/gke/route-trigger-cloud-firestore)\n- [Workflows](/eventarc/docs/workflows/route-trigger-cloud-firestore)\n\nEventarc offers a standardized solution to manage the flow of\nstate changes, called *events*, between decoupled microservices. When triggered,\nEventarc routes these events to\nvarious destinations while managing delivery, security, authorization,\nobservability, and error-handling for you.\n| **Note:** Eventarc events use the [`CloudEvents`](https://cloudevents.io/) specification.\n\nExample use cases\n-----------------\n\nAn event-driven architecture is a system design pattern where services react\nto changes in state known as events. You can use this pattern alongside the\nscalability of Firestore to add more features to your app.\nFor example, you might add the following capabilities:\n\n- Interoperability between different technology stacks\n\n Replicate your data and transform it before sending it to an\n analytics system.\n- Parallel processing\n\n Fan out operations for parallel processing. If you have multiple systems that\n operate based on entity changes, you can use the push-based streams in each\n consumer and route the event to multiple consumers.\n- Push-based event streams\n\n Build push-based messaging designs. Clients can receive notifications without needing to poll remote services. Without the polling latency,\n you can better perform on-the-fly data processing and real-time analysis.\n- State monitoring and alerting\n\n Use an event-driven architecture to add custom\n metrics to your database operations. Monitor and receive alerts on changes and updates. Detect anomalies.\n\nLimitations\n-----------\n\nNote the following limitations for Datastore mode triggers for\nEventarc:\n\n- Ordering is not guaranteed. Rapid changes can trigger events in an unexpected order.\n- Events are delivered *at least* once.\n\n Make sure your event handler is idempotent and avoid producing unexpected results\n or side effects when an event is delivered more than once. Refer to\n [Building idempotent functions](https://cloud.google.com/blog/products/serverless/cloud-functions-pro-tips-building-idempotent-functions) to learn more.\n- A trigger is associated with a single database. You cannot create a trigger that matches multiple databases.\n\n- Deleting a database does not automatically delete any triggers for that database. The\n trigger stops delivering events but continues to exist until you [delete the trigger](/eventarc/docs/managing-triggers#trigger-delete).\n\nEventarc and Firestore in Datastore mode locations\n--------------------------------------------------\n\nEventarc does not support multi-regions for Firestore event\ntriggers, but you can still create triggers for Firestore databases\nin multi-region locations. Eventarc maps Firestore\nmulti-region locations to the following Eventarc regions:\n\nDatastore mode and Native mode event interoperability\n-----------------------------------------------------\n\nEventarc supports event triggers for both Datastore mode and Native\nmode. These event triggers are interoperable with both database types.\nA Firestore in Native mode database can receive Datastore\nevents, and a Firestore in Datastore mode database can receive\nNative mode events.\n\nEvent interoperability lets you share Eventarc code across\nFirestore databases of different types.\n\n### Event conversions\n\nIf you apply a Native mode event trigger to a Datastore\nmode database, Eventarc makes the following conversions:\n\n- The namespace of the entity is stored in the event's `PartitionId` attribute.\n- Embedded entities are converted to Native mode `map` types.\n\nWhat's next\n-----------\n\n- Learn about [event-driven architectures](/eventarc/docs/event-driven-architectures)."]]