Create event-driven architectures with Eventarc

You can useEventarc andFirestore to buildevent-driven architectures.Firestore triggers forEventarc generate events from changesto a particular documents in your database. The trigger can route events to asupported destination:

• Cloud Run functions (2nd gen) which supports theCloud Client Libraries and theFirebase SDK
• Cloud Run
• Google Kubernetes Engine
• Workflows

Eventarc offers a standardized solution to manage the flow ofstate changes, calledevents, between decoupled microservices. When triggered,Eventarc routes these events tovarious destinations while managing delivery, security, authorization,observability, and error-handling for you.

Note: Eventarc events use theCloudEvents specification.

Limitations

Note the following limitations for Firestore triggers forEventarc:

• Ordering is not guaranteed. Rapid changes can trigger events in an unexpected order.

• Events are deliveredat least once.

  Make sure your event handler is idempotent and avoid producing unexpected resultsor side effects when an event is delivered more than once. Refer toBuilding idempotent functions to 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. Thetrigger stops delivering events but continues to exist until youdelete the trigger. If the database is recreated, any associated triggers will also need to be deleted and recreated to restore event delivery.

Differences between Cloud Run functions 2nd gen and 1st gen

Cloud Run functions (2nd gen) uses Eventarc events for all runtimes.Previously, Cloud Run functions (1st gen) used Eventarc events foronly some runtimes.Eventarc events introduce the following differences fromCloud Run functions (1st gen).

• The Firestore triggers for Eventarc supportadditional destinations besides Cloud Run functions. You can routeCloudEventsto a number ofdestinations including,but not limited to Cloud Run, GKE, andWorkflows.

• Firestore triggers for Eventarc retrieve thetrigger definition at the start of a database write operation and usesthat definition to decide if Firestore should emit an event. Thewrite operation does not take into account any changes to trigger definitionthat might happen as it runs.

  Cloud Run functions (1st gen) retrieves the trigger definition during theevaluation of the database write, and changes to the trigger duringevaluation can affect if Firestore emits an event or not.

Datastore mode and Native mode event interoperability

Eventarc supports event triggers for both Datastore mode and Nativemode. These event triggers are interoperable with both database types.A Firestore in Native mode database can receive Datastoreevents, and a Firestore in Datastore mode database can receiveNative mode events.

Event interoperability lets you share Eventarc code acrossFirestore databases of different types.

Event conversions

If you apply a Native mode event trigger to a Datastoremode database, Eventarc makes the following conversions:

• The namespace of the entity is stored in the event'sPartitionId attribute.
• Embedded entities are converted to Native modemap types.

What's next

• Learn aboutevent-driven architectures.