An view of event driven solutions¶

Good Reading

Details of this picture follow the picture

The following text was provided by Google Gemini 2.0. The pictures were drawn by Gary Zeien. The output was reviewed.

Please provide an explanation of this picture that includes details on the key objects in the picture, the relationships, and a summary of the key points being covered in this picture.

This diagram illustrates an event-driven architecture pattern, emphasizing the flow of events, actions triggered by those events, and the role of policies and auditing. It's a design for a system that reacts to events in real-time or near real-time.

Key Objects:

• Event: A significant change in state or occurrence within the system. Each event has a unique type and is formatted consistently (e.g., JSON).
• Event Provider: The source that generates events (e.g., a user action, a sensor reading, a system status change).
• Event Bus Service: A message broker or event streaming platform that receives events from providers and distributes them to subscribers. It uses "Topics" to categorize events.
• Topic: A category or channel within the Event Bus Service to which events are published and from which they are consumed.
• Action: A specific task or operation that is performed in response to an event. There is a design point emphasizing a 1:1 relationship between Event Type and Action.
• Actions Service (Dynamically Scalable): The service responsible for executing actions. It subscribes to topics on the Event Bus Service.
• Action Implementation Services: The services that perform the actual work associated with an action (e.g., Workflow Service, Automation Service).
• Supporting Service (Data Enrichment): Services that provide additional data or context to actions.
• Analytics/ML/AI Service (Analyze): Services that analyze events and potentially trigger new events or provide insights.
• Data Lake: A central repository for storing event data for analysis and reporting.
• Analytics: The process of analyzing data in the Data Lake.
• Policy Mgmt Service: A service that manages business policies, authorization policies, SLA policies, audit policies, etc.
• Policy Repository: A storage location for policies.
• Policy (Rego language): Policies defined in a formal language (e.g., Rego, used by Open Policy Agent).
• Open Policy Agent (OPA) Engine: A policy engine that evaluates policies against incoming requests or events.
• Audit Service: A service that logs and records events and actions for auditing and compliance purposes.
• Audit Log: The stored records of events and actions.
• Organizational "Conscience": Represents the set of business rules, policies, and compliance requirements that govern the system.

Relationships and Flow:

1. Event Provider publishes Events to Event Bus: The Event Provider generates an Event and publishes it to a specific Topic on the Event Bus Service.
2. Actions Service subscribes to Topics: The Actions Service subscribes to relevant Topics on the Event Bus Service to receive Events.
3. Event triggers Action: When an Event arrives on a subscribed Topic, the Actions Service triggers the corresponding Action.
4. Action uses Action Implementation Services: The Action Logic uses specific Action Implementation Services to perform the required tasks.
5. Actions can use Supporting Services: Actions can use Supporting Services to enrich data or get additional context.
6. Events are stored in Data Lake: Events are persisted in a Data Lake for later analysis by the Analytics/ML/AI Service.
7. Policies are evaluated by OPA: The Policy Mgmt Service manages policies stored in the Policy Repository. The OPA Engine evaluates these policies against Events or Actions to enforce organizational rules.
8. Audit Service logs Events and Actions: The Audit Service records all Events and Actions in an Audit Log for auditing and compliance.

Key Points:

• Decoupling: The Event Bus Service decouples Event Providers from Actions, allowing them to evolve independently.
• Real-time or Near Real-time Reaction: The system reacts to events as they occur, enabling real-time or near real-time processing.
• Scalability: The Actions Service can be dynamically scaled to handle varying event volumes.
• Policy Enforcement: Policies are used to govern the behavior of the system and ensure compliance.
• Auditing and Logging: Comprehensive auditing provides a record of what happened, when, and what actions were taken.
• Standardized Event Format: The diagram emphasizes the importance of a standard format (e.g., JSON) for events.
• 1:1 Event Type to Action (Design Point): The diagram highlights a design consideration where there is a one-to-one mapping between an event type and a specific action. This simplifies design and understanding of the system.
• Inline Action Code vs. Service (Design Point): The diagram notes that action logic could be implemented inline within the Actions Service or as separate services.

In summary, this diagram illustrates a robust event-driven architecture that allows for flexible and scalable processing of events, with strong emphasis on policy enforcement and auditing. It's a valuable pattern for building responsive and adaptable systems.