Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Criar arquiteturas orientadas a eventos com o Eventarc
É possível usar o Eventarc e o
Firestore para criar
arquiteturas orientadas a eventos.
Os gatilhos do Firestore para
o Eventarc geram eventos de mudanças
em documentos específicos no seu banco de dados. O gatilho pode rotear eventos para um destino compatível:
Eventarc oferece uma solução padronizada para gerenciar o fluxo de
alterações de estado, chamadas de eventos, entre microsserviços separados. Quando acionado,
o Eventarc encaminha esses eventos para
vários destinos, gerenciando a entrega, a segurança, a autorização, a observabilidade e o tratamento de erros para você.
Limitações
Observe as seguintes limitações para gatilhos do Firestore 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.
Verifique se o manipulador de eventos é idempotente e evite produzir resultados inesperados
ou efeitos colaterais quando um evento é entregue 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
acionador deixa de entregar eventos, mas continua existindo até que você o exclua. Se o banco de dados for recriado, todos os gatilhos associados também precisarão ser excluídos e recriados para restaurar a entrega de eventos.
Locais do Eventarc e do Firestore
O Eventarc não oferece suporte a multirregiões para gatilhos de eventos do Firestore no modo nativo, mas ainda é possível criar gatilhos para bancos de dados do Firestore em locais multirregionais. O Eventarc mapeia os locais multirregionais do Firestore para as seguintes regiões do Eventarc:
Multirregião do Firestore
Região do Eventarc
nam5
us-central1
eur3
europe-west4
Diferenças entre as funções do Cloud Run de 2ª e 1ª geração
As funções do Cloud Run (2ª geração) usam eventos do Eventarc para todos os ambientes de execução.
Antes, as funções do Cloud Run (1ª geração) usavam eventos do Eventarc apenas para alguns ambientes de execução.
Os eventos do Eventarc apresentam as seguintes diferenças em relação às funções do Cloud Run (1ª geração).
Os gatilhos do Firestore para o Eventarc são compatíveis com
outros destinos além das funções do Cloud Run. É possível encaminhar CloudEvents
para vários destinos, incluindo, sem limitação, o Cloud Run, o GKE e o
Workflows.
Os acionadores do Firestore para o Eventarc recuperam a
definição do acionador no início de uma operação de gravação do banco de dados e usam
essa definição para decidir se o Firestore deve emitir um evento. A operação de gravação não considera mudanças na definição do gatilho que possam ocorrer durante a execução.
O Cloud Run functions (1ª geração) recupera a definição do gatilho durante a
avaliação da gravação do banco de dados, e as mudanças no gatilho durante a
avaliação podem afetar se o Firestore emite um evento ou não.
Interoperabilidade de eventos do modo Datastore e do modo nativo
O Eventarc é compatível com gatilhos de eventos para o modo Datastore e o modo
nativo. Esses gatilhos 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.
Com a interoperabilidade de eventos, é possível compartilhar código do Eventarc em bancos de dados do Firestore de diferentes tipos.
Conversões de evento
Se você aplicar um gatilho de evento do modo nativo a um banco de dados do modo 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-08-25 UTC."],[],[],null,["# Create event-driven architectures with Eventarc\n===============================================\n\nYou can use [Eventarc](/eventarc/docs/overview) and\nFirestore to build\n[event-driven architectures](/eventarc/docs/event-driven-architectures).\nFirestore triggers for\nEventarc generate events from changes\nto a particular documents 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) which supports the [Cloud Client Libraries](/firestore/docs/extend-with-functions-2nd-gen) and the [Firebase SDK](https://firebase.google.com/docs/firestore/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\nLimitations\n-----------\n\nNote the following limitations for Firestore 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). If the database is recreated, any associated triggers will also need to be deleted and recreated to restore event delivery.\n\nEventarc and Firestore locations\n--------------------------------\n\nEventarc does not support multi-regions for Firestore in Native Mode 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\nDifferences between Cloud Run functions 2nd gen and 1st gen\n-----------------------------------------------------------\n\nCloud Run functions (2nd gen) uses Eventarc events for all runtimes.\nPreviously, Cloud Run functions (1st gen) used Eventarc events for\n[only some runtimes](/functions/docs/writing/write-event-driven-functions).\nEventarc events introduce the following differences from\n[Cloud Run functions (1st gen)](/firestore/docs/extend-with-functions).\n\n- The Firestore triggers for Eventarc support\n additional destinations besides Cloud Run functions. You can route `CloudEvents`\n to a number of [destinations](/eventarc/docs/event-providers-targets) including,\n but not limited to Cloud Run, GKE, and\n Workflows.\n\n- Firestore triggers for Eventarc retrieve the\n trigger definition at the start of a database write operation and uses\n that definition to decide if Firestore should emit an event. The\n write operation does not take into account any changes to trigger definition\n that might happen as it runs.\n\n Cloud Run functions (1st gen) retrieves the trigger definition during the\n evaluation of the database write, and changes to the trigger during\n evaluation can affect if Firestore emits an event or not.\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)."]]