[[["わかりやすい","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-04 UTC。"],[[["\u003cp\u003eEvent-driven architecture is a software design pattern where microservices react to state changes (events), which can either carry state information or act as identifiers.\u003c/p\u003e\n"],["\u003cp\u003eEvents in this architecture are immutable records of occurrences, persistable indefinitely, and consumed as needed, regardless of whether a service applies logic upon them.\u003c/p\u003e\n"],["\u003cp\u003eThe event router acts as a central hub, linking event producers and consumers, managing subscriptions, and executing responses to events asynchronously.\u003c/p\u003e\n"],["\u003cp\u003eEvent-driven architectures offer loose coupling, improved developer agility, asynchronous eventing, push-based messaging, real-time event streams, and simplified auditing.\u003c/p\u003e\n"],["\u003cp\u003eWhen designing an event-driven system, consider event source reliability, handling of multiple asynchronous requests, dynamic tracking, and data deduplication and ordering for state rebuilding.\u003c/p\u003e\n"]]],[],null,["# Event-driven architectures\n\n[Advanced](/eventarc/advanced/docs/overview) [Standard](/eventarc/standard/docs/overview)\n\nAn *event-driven architecture* is a software design pattern in which\nmicroservices react to changes in state, called *events*. Events can either\ncarry a state (such as the price of an item or a delivery address) or events can\nbe identifiers (a notification that an order was received or shipped, for\nexample). The events trigger microservices that work together to achieve a\ncommon goal, but don't have to know anything about each other except the event\nformat. Although operating together, each microservice can apply a different\nbusiness logic, and emit its own output events.\n\nAn event has the following characteristics:\n\n- It is a record of something that has happened.\n- It captures an immutable fact that cannot be changed or deleted.\n- It occurs whether or not a service applies any logic upon consuming it.\n- It can be persisted indefinitely, at a large scale, and consumed as many times as necessary.\n\nIn an event-driven system, events are generated by **event producers** , ingested\nand filtered by an **event router** (or broker), and then fanned out to the\nappropriate **event consumers** (or sinks). The events are forwarded to the\nconsumers based on subscriptions defined by one or more matching *enrollments*\n(when using [Eventarc Advanced](/eventarc/advanced/docs/overview)) or\none or more matching *triggers* (when using\n[Eventarc Standard](/eventarc/standard/docs/overview)). These three\ncomponents---event producers, event router, event consumers---are decoupled and can\nbe independently deployed, updated, and scaled:\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nThe event router links the different services and is the medium through which\nmessages are sent and received. It executes a response to the original event\ngenerated by an event producer and sends this response downstream to the\nappropriate consumers. Events are handled asynchronously and their outcomes are\ndecided when a service reacts to an event or is impacted by it, as in the\nfollowing diagram of a very simplified event flow:\n\n\u003cbr /\u003e\n\nWhen to use event-driven architectures\n--------------------------------------\n\nConsider the following usages when designing your system.\n\n- **To monitor and receive alerts** for any anomalies or changes to storage buckets, database tables, virtual machines, or other resources.\n- **To fan out a single event** to multiple consumers. The event router will push the event to all the appropriate consumers, without you having to write customized code. Each service can then process the event in parallel, yet differently.\n- **To provide interoperability between different technology stacks** while maintaining the independence of each stack.\n- **To coordinate systems and teams** operating in and deploying across different regions and accounts. You can reorganize the ownership of microservices. There are fewer cross-team dependencies and you can react more quickly to changes that would otherwise be impeded by barriers to data access.\n\nBenefits of event-driven architectures\n--------------------------------------\n\nThese are some of the advantages when building an event-driven architecture.\n\n### Loose coupling and improved developer agility\n\nEvent producers are logically separated from event consumers. This\ndecoupling between the production and consumption of events means that services\nare interoperable but can be scaled, updated, and deployed independently of each\nother.\n\nLoose coupling reduces dependencies and lets you implement services in\ndifferent languages and frameworks. You can add or remove event producers and\nreceivers without having to change the logic in any one service. You don't need\nto write custom code to poll, filter, and route events.\n\n### Asynchronous eventing and resiliency\n\nIn an event-driven system, events are generated asynchronously, and can be\nissued as they happen without waiting for a response. Loosely coupled components\nmeans that if one service fails, the others are unaffected. If necessary, you\ncan log events so that the receiving service can resume from the point of\nfailure, or replay past events.\n\n### Push-based messaging, real-time event streams, and lower costs\n\nEvent-driven systems allow for push-based messaging and clients can receive\nupdates without needing to continuously poll remote services for state changes.\nThese pushed messages can be used for on-the-fly data processing and\ntransformation, and real-time analysis. Moreover, with less polling, there is a\nreduction in network I/O, and decreased costs.\n\n### Simplified auditing and event sourcing\n\nThe centralized location of the event router simplifies auditing, and lets you\ncontrol who can interact with a router, and which users and resources have\naccess to your data. You can also encrypt your data both in transit and at rest.\n\nAdditionally, you can make use of event sourcing, an architectural pattern that records\nall changes made to an application's state, in the same sequence that they were\noriginally applied. Event sourcing provides a log of immutable events which can\nbe kept for auditing purposes, to recreate historic states, or as a canonical\nnarrative to explain a business-driven decision.\n\nArchitectural considerations\n----------------------------\n\nAn event-driven architecture might require that you approach your application\ndesign in a new way. Although well suited for applications that make use of\nmicroservices or decoupled components, you should also consider the following:\n\n- *Can your event source guarantee delivery if you need to process every single\n event?*\n\n It should be a durable and reliable event source.\n- *Can your application handle multiple asynchronous requests?*\n\n Your system performance shouldn't rely on global scope or inelastic databases.\n- *How do you want to track your event flow?*\n\n An event-driven architecture supports dynamic tracking using monitoring\n services, but not static tracking using code analysis.\n- *Do you want to use the data in your event source to rebuild state?*\n\n You should consider how to ensure that your data is deduplicated and ordered.\n\nWhat's next\n-----------\n\n- To understand how Eventarc Advanced handles events, see the [Eventarc Advanced overview](/eventarc/advanced/docs/overview).\n- To understand how Eventarc Standard handles events, see the [Eventarc Standard overview](/eventarc/standard/docs/overview)."]]
