An event stream is an ordered, continuously produced sequence of events that consumers can read without changing events after creation. In an engineering platform, a primary integration orchestrator can publish team-related events while separate services respond to the events relevant to their configuration work. section 4.3.3
Processing platform events through separate consumers offers several operational advantages:
- Services can be developed and deployed independently because each needs to know only the events it consumes. section 9.3
- Asynchronous processing distributes work across services; a failed service need not stop others while the stream remains functional. section 9.3
- New integrations can publish or consume relevant events without substantially changing existing services. section 9.3
Keeping team configuration aligned
When a team sync event arrives, a namespace API can check that the team's production and nonproduction namespaces have the required resource allocations and Istio annotations. If actual configuration differs from the desired configuration, the API resets it. Other consumers can respond to the same kind of event to manage Terraform Cloud, Jira, or observability configuration. This separates responsibility for each integration without making developers coordinate those configurations manually. section 4.3.3
Figure 4.11 As long as there is a single, primary platform integration orchestrator modeled around the primary customer persona (the team) that maintains and populates this standard event stream, it is easy for these integration activities to evolve with our platform.
The diagram shows how one team-centered orchestrator can maintain a standard event stream while integration responsibilities evolve independently. section 4.3.3
Keep the distinction clear: the stream communicates events; each consumer remains responsible for checking and maintaining the configuration it owns. Start with the events and integrations the platform needs, then add consumers as responsibilities grow. section 4.3.3 section 9.3
