Based on my understanding Linear's talk and GitLab current RT approach, I made some rough diagrams to help illustrate where I think GitLab could build towards / some of the opportunities I'm seeing.

Please interpret these as a PM trying to wrestle with ideas and not as a technical system diagram; my understanding of these systems is probably missing / overlooking key concerns.

https://lucid.app/lucidchart/7a58c084-f4cc-4643-8e53-2456b2f47db9/edit?invitationId=inv_71ad636f-26d3-4889-8da6-c74408d03f2a&page=0_0#

I think these make sense as evolutionary steps, thanks for sharing! I think we should verify with developers from the stage groups who own MRs and pipelines and who have worked with (or are working on) our existing realtime APIs and infra to see if the first 2 actually reflect the status quo.

As far as introducing an event bus goes, I know Fabio has been working toward introducing something like that: https://docs.gitlab.com/ee/development/event_store.html

I looked at that implementation a while ago and it is not really an event bus in the traditional sense (there is no state in message delivery, it is just the observer pattern with consumers and producers being decoupled from each other.) But it might do what we need. Another concern I have with EventStore is that it's built on top of Sidekiq. This might not be sufficient to capture all relevant business events in a real-time setup. But would need to explore this through specific use cases.

We will want to catch up with folks who are more involved in architectural decisions and design at GitLab since this isn't something our team has been traditionally been involved with and this is also not specific to real-time but rather a larger architectural change GitLab might be undergoing.