Overview of event-driven architectures with Eventarc
Stay organized with collectionsSave and categorize content based on your preferences.
You can useEventarcand
Firestore in Datastore mode to build
event-driven architectures.
Firestore in Datastore mode provides triggers for
Eventarc that generate events from changes
to a particular entity in your database. The trigger can route events to asupported destination:
Eventarc offers a standardized solution to manage the flow of
state changes, calledevents, between decoupled microservices. When triggered,
Eventarc routes these events to
various destinations while managing delivery, security, authorization,
observability, and error-handling for you.
Example use cases
An event-driven architecture is a system design pattern where services react
to changes in state known as events. You can use this pattern alongside the
scalability of Firestore to add more features to your app.
For example, you might add the following capabilities:
Interoperability between different technology stacks
Replicate your data and transform it before sending it to an
analytics system.
Parallel processing
Fan out operations for parallel processing. If you have multiple systems that
operate based on entity changes, you can use the push-based streams in each
consumer and route the event to multiple consumers.
Push-based event streams
Build push-based messaging designs. Clients can receive notifications without needing to poll remote services. Without the polling latency,
you can better perform on-the-fly data processing and real-time analysis.
State monitoring and alerting
Use an event-driven architecture to add custom
metrics to your database operations. Monitor and receive alerts on changes and updates. Detect anomalies.
Limitations
Note the following limitations for Datastore mode triggers for
Eventarc:
Ordering is not guaranteed. Rapid changes can trigger events in an unexpected order.
Events are deliveredat leastonce.
Make sure your event handler is idempotent and avoid producing unexpected results
or side effects when an event is delivered more than once. Refer toBuilding idempotent functionsto learn more.
A trigger is associated with a single database. You cannot create a trigger that matches multiple databases.
Deleting a database does not automatically delete any triggers for that database. The
trigger stops delivering events but continues to exist until youdelete the trigger.
Eventarc and Firestore in Datastore mode locations
Eventarc does not support multi-regions for Firestore event
triggers, but you can still create triggers for Firestore databases
in multi-region locations. Eventarc maps Firestore
multi-region locations to the following Eventarc regions:
Firestore multi-region
Eventarc region
nam5
us-central1
eur3
europe-west4
Datastore mode and Native mode event interoperability
Eventarc supports event triggers for both Datastore mode and Native
mode. These event triggers are interoperable with both database types.
A Firestore in Native mode database can receive Datastore
events, and a Firestore in Datastore mode database can receive
Native mode events.
Event interoperability lets you share Eventarc code across
Firestore databases of different types.
Event conversions
If you apply a Native mode event trigger to a Datastore
mode database, Eventarc makes the following conversions:
The namespace of the entity is stored in the event'sPartitionIdattribute.
Embedded entities are converted to Native modemaptypes.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 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)."]]