## Background * [Product requirements document](https://docs.google.com/document/d/1DtzVsnKWl_oaIP3-VzQk-dfjsoMVaiTvzSMmAYkR2wc/edit) (internal only) * [PRD overview slides](https://docs.google.com/presentation/d/1kAyxC-1oXeXKA3oDeAGY8QVr6IJ4a8MD7YW4-797HEY/edit#slide=id.g12b319f6181_0_0) (internal only) * [PRD readout](https://youtu.be/ulbaAkePMn4) (internal only) ## Problems to solve * Product features that need to interact with cross-platform functionality are implemented in a point-to-point fashion that requires intense coordination and collaboration across groups and stages, limiting feature velocity. * Multiple product teams are introducing event-driven features that are focused primarily on their use cases rather than on platform-wide capabilities. * GitLab Duo needs a way to publish events to and consume events from the Rails monolith. Our existing eventing technology is tightly coupled to Rails and not accessible to the AI Gateway. ## Use cases A common product event platform will allow GitLab to ship innovative features for the following use cases: * Analytics and observability: Analyze product data to inform decisions * Auditing and compliance: Review history of system changes and interactions * Collaboration: Work with others (human or AI) to accomplish a common goal * Integrations: Connect externals systems into GitLab * Workflow automation: Perform one or more tasks within the GitLab platform We have identified a broad collection of features focused on these use cases that would benefit from having access to this platform. Some of these are net-new initiatives for GitLab, and some represent our previous attempts to implement event-driven functionality in the product. Analytics and observability The Product Usage Data Working Group has been working to introduce a data streaming platform specifically to address the Analytics and observability use case. Note that the name of the working group is more narrow than the scope they’re encompassing: they’re solving for all analytics and observability use cases in GitLab, both internal and customer-facing – including self-managed deployments. This includes features like: * Product Analytics * Value Stream Management * Observability features like logs, metrics, and alerts * AI impact dashboard Members of the working group recognize that the product events platform proposed here is solving the same class of problems for other use cases (especially automation and collaboration). Engineering Managers involved in these discussions are optimistic we can meet all of these needs with a single technology platform. Our groups are coordinating to validate whether this is the case and to support each other to reduce duplicated effort and improve time-to-market. See One platform or two? for more analysis on this topic. They have already completed extensive analysis for the Analytics and observability use case. Accordingly, this document explores the other use case that would benefit from a common product event platform. ### Net-new initiatives * GitLab Duo * AutoFlow * CI events * Notifications ### Existing functionality that could be enhanced * Audit logs * Event API / Activity stream * Outbound hooks (generic webhooks, file hooks, system hooks, etc) * Policies * Real-time events (GraphQL subscriptions, server-side events) * Value Stream Analytics (comprehensive events for custom stage configuration) ### Future possibilities * Knowledge base for AI: “show me the last 5 comments I made” * Integrate GitLab with customer k8s environment ## Requirements <table> <tr> <th> </th> <th align="center"> [Minimal](https://gitlab.com/groups/gitlab-org/-/epics/15512) </th> <th align="center"> [Viable](https://gitlab.com/groups/gitlab-org/-/epics/15515) </th> <th align="center">Competitive</th> <th align="center">Complete</th> </tr> <tr> <td>Published events</td> <td align="center"> **Basic** events for **key** domain objects </td> <td align="center"> **All** events for **key** domain objects </td> <td align="center"> **Basic** events for **all** domain objects </td> <td align="center"> **All** events for **all** domain objects </td> </tr> <tr> <td>Consumers</td> <td align="center">Monolith only</td> <td align="center">All internal services</td> <td align="center">Third-party tools</td> <td align="center">Third-party tools</td> </tr> <tr> <td>Producers</td> <td align="center">Monolith only</td> <td align="center">All internal services</td> <td align="center">Third-party tools</td> <td align="center">Third-party tools</td> </tr> <tr> <td>GitLab.com</td> <td align="center"> :heavy_check_mark: </td> <td align="center"> :heavy_check_mark: </td> <td align="center"> :heavy_check_mark: </td> <td align="center"> :heavy_check_mark: </td> </tr> <tr> <td>Dedicated</td> <td align="center"> :heavy_check_mark: </td> <td align="center"> :heavy_check_mark: </td> <td align="center"> :heavy_check_mark: </td> <td align="center"> :heavy_check_mark: </td> </tr> <tr> <td>Self-managed</td> <td align="center"> :heavy_check_mark: </td> <td align="center"> :heavy_check_mark: </td> <td align="center"> :heavy_check_mark: </td> <td align="center"> :heavy_check_mark: </td> </tr> <tr> <td>Air-gapped</td> <td align="center"> :heavy_check_mark: </td> <td align="center"> :heavy_check_mark: </td> <td align="center"> :heavy_check_mark: </td> <td align="center"> :heavy_check_mark: </td> </tr> <tr> <td>Cells-ready</td> <td align="center"> :heavy_check_mark: </td> <td align="center"> :heavy_check_mark: </td> <td align="center"> :heavy_check_mark: </td> <td align="center"> :heavy_check_mark: </td> </tr> <tr> <td> Underlying technology </td> <td align="center">Sidekiq</td> <td align="center"> NATS\* </td> <td align="center"> NATS\* </td> <td align="center"> NATS\* </td> </tr> <tr> <td>Throughput</td> <td align="center">1x</td> <td align="center">10x</td> <td align="center">100x</td> <td align="center">100x</td> </tr> </table> \*NATS is the current preference, but we're still evaluating alternatives ## Iteration plan _See https://gitlab.com/gitlab-org/gitlab/-/issues/478611+._ ## Stakeholders ### Responsible * _We will decide who is responsible for implementing this proposal at a later date_ ### Accountable * Core Platform PMs * _EM will be determined when deciding who implements this. It could be the Foundations EM, or someone else._ ### Consulted * PM/EM for initiatives using product event platform * PM/EM for Distribution group (if introducing new technology) * PM/EM for Database group (to ensure we provide sufficient safeguards for DB health) * EM for quality team (if changing reference architecture) * Product Usage Data Working Group * Engineers with experience in eventing systems ### Informed * PMs/EMs for future use cases * Product and engineering leadership ## Open questions * **Technology**: Can our existing technology stack meet the above requirements? If not, what technology should we introduce into the platform to meet them? * **Cost**: Can we accomplish this with open-source software, or do we need a commercial product? If commercial, what are the costs of that? Either way, what are the additional compute & storage demands for the proposed product event platform? * **Staffing**: How many engineers do we need to deliver this in a reasonable timeframe? Do we have the skills we need internally, or do we need to hire a dedicated skill set for this? How will we ensure maintenance and ongoing support for this platform? * **Event structure**: Does the CloudEvents specification meet our needs, or do we need something custom? What’s the right granularity for events? Should they be more RPC-like (“Package published”) or more REST-like (“Package updated”, with an attribute “published: true”)? * **Performance**: What are the performance requirements for the platform? What kind of latency is acceptable for consumers? How much room do we realistically have for our current event store approach?