[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-05 (世界標準時間)。"],[[["\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)."]]
