Event-driven architecture lets components coordinate by publishing events and subscribing to the events they need. A publisher does not have to run every downstream integration itself. This matters as an engineering platform grows: configuration and deployment work can be distributed without making one service responsible for every tool and cluster. section 9.3 section 4.3.3
For team onboarding, a Teams API can maintain the authoritative team record and publish sync_team events. Subscribers can then maintain their own configurations, such as namespaces, Jira settings, or observability access. Responsibility for an integration can move to the team that owns that system without changing the primary onboarding interface. section 4.3.3 section 8.5
The pattern is useful when independent services need to react to the same change:
- Decouple deployment: subscribers need to know which events matter to them, not the implementation of every other service. section 9.3
- Distribute processing: asynchronous subscribers can handle work across multiple services, while unaffected services can continue if one fails and the event stream remains functional. section 9.3
- Keep configuration resilient: recurring team sync events let integration APIs check actual settings and restore the desired configuration after unintended changes. section 4.3.3 section 8.5
Cluster configuration from Git events
A service in each cluster can watch a Git repository and perform a Helm upgrade when its configuration changes. GitHub webhooks can publish events; Flux or ArgoCD can subscribe to repository events such as pushes or tags. This moves deployment work to cluster-level services rather than relying on one central deployer. section 9.3 section 9.4
Figure 8.9 A “teams” API can be the interface to onboard a team and maintain the authoritative database for customer teams. This API will maintain the correct RoleBindings on the respective clusters. It can also populate the “sync team” events stream to which other services can subscribe.
The diagram separates the authoritative Teams API, its cluster RoleBindings, and the sync-team event stream consumed by other services. section 8.5
Start with an authoritative API and an event tied to a clear domain change. Add subscribers for specific integration responsibilities, including those owned outside the platform team. Keep the user-facing experience unified while allowing those integrations to evolve independently. section 4.3.3 section 8.5
