feat: Introduce MessageBus for Event Driven architecture

[hariombalhara]

What does this PR do?

Introducing MessageBus

Note: The name is chosen to be MessageBus, and not EventBus, so that it is not confused with Cal.com Events.

Overview

Every feature in @calcom/features should define the actions it takes for a specific lifecycle event during a request. This ensures that the logic is organized, modular, and easily testable.

Example

For instance, the message messages/booking.created/handler defines what happens when a booking.created event occurs.

Extending MessageBus

For more complex request flows, developers can extend the MessageBus to define their own Buses and use those Buses.

Example:

A BookingMessageBus could define messages such as:

• booking.created
• booking.rescheduled
• booking.requestRescheduled

Benefits

• Cohesion: All actions related to a lifecycle event are grouped together.
• Testability: Individual handlers can be tested in isolation.
• Extensibility: Custom message buses can be easily created for specific workflows.

This approach streamlines event handling, reduces coupling, and makes the system more maintainable.

Visual Demo (For contributors especially)

A visual demonstration is strongly recommended, for both the original and new change (video / image - any one).

Video Demo (if applicable):

• Show screen recordings of the issue or feature.
• Demonstrate how to reproduce the issue, the behavior before and after the change.

Image Demo (if applicable):

• Add side-by-side screenshots of the original and updated change.
• Highlight any significant change(s).

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox.
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

• Are there environment variables that should be set?
• What are the minimal test data to have?
• What is expected (happy path) to have (input and output)?
• Any other important info that could help to test that PR

Checklist

• I haven't read the contributing guide
• My code doesn't follow the style guidelines of this project
• I haven't commented my code, particularly in hard-to-understand areas
• I haven't checked if my changes generate no new warnings

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

✨ Finishing touches

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch booking-refactor-event-bus

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

Hey there and thank you for opening this pull request! 👋🏼

We require pull request titles to follow the Conventional Commits specification and it looks like your proposed title needs to be adjusted.

Details:

No release type found in pull request title "event-bus". Add a prefix to indicate what kind of release this pull request corresponds to. For reference, see https://www.conventionalcommits.org/

Available types:
 - feat: A new feature
 - fix: A bug fix
 - docs: Documentation only changes
 - style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
 - refactor: A code change that neither fixes a bug nor adds a feature
 - perf: A code change that improves performance
 - test: Adding missing tests or correcting existing tests
 - build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
 - ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
 - chore: Other changes that don't modify src or test files
 - revert: Reverts a previous commit

[hariombalhara]

• fix: same yarn lock #24007
• feat: Introduce MessageBus for Event Driven architecture #23839 👈 (View in Graphite)
• feat: [Booking flow refactor - 3] Rename booking handlers to service names and remove Prisma import from InstantBookingCreateService #23682 : 3 other dependent PRs (#23797 , #24022 , #24025 )
• chore: [Booking flow refactor - 2] Integrate Booking services #23156 : 2 other dependent PRs (#23283 , #23296 )
• chore: [Booking Refactor - Preparation - 0]Move modules required by RegularBookingService to moduleLoader format #23740
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
cal	Ignored			Sep 23, 2025 0:31am
cal-eu	Ignored			Sep 23, 2025 0:31am

[volnei]

hey @hariombalhara, I have some points of improvement that I'd love to us to take in account. This is not regarding the implementation, which is good, but more related to resilience and performance.

I really value the event mechanism and I think we should go forward with it, but maybe we should rethink it to get all benefits.

What's not that good:

1. Resilience:
   1.1. retries - I can't see any retry mechanism which make this implementation weak and not trustable as it should be;
   1.2. idempotency - Also important to have some control to avoid duplicated events being fired;
   1.3. backup - if the server restarted or process goes down the events are gone 💥
2. Fault tolerance:
   2.1. As it is implemented if we have a defect handler it will break all subsequent, it should isolate the exceptions;
3. Tests
   3.1. No tests implemented, but it's okay since it's in draft yet;
4. Implementation
   4.1. BookingMessageBus should be a singleton (DI)

What I think is better for this case:

• If the objective is something really weak (what I don't agree) the Node Events API is good enough, seems that we're reimplementing it;
• If the objective is that to be a definitive guide I would recommend to implement it using Redis pub/sub or Redis Streams (even better) that will address the main resilience points.

cc @keithwillcode

[hariombalhara]

A handler for trigger.dev would be defined here.

[emrysal]

This service should probably move to the privateLink feature also.

[hariombalhara]

Yeah certainly.But I didn't want to do any other refactor as part of this PR.

[hariombalhara]

Closing it as per internal discussion. We don'tt want to pursue it further for now, will be re-evaluated if we really need it.