In the realm of modern software solutions, catering to diverse user needs while maintaining data integrity and security is a complex challenge. RapidStream, has leveraged the powerful authentication and authorization tool Clerk to craft an approach that balances multi-tenancy, security, scalability, and user experience. In this article, we delve into the architecture and strategies that power RapidStream.

The Foundation: Auth&Auth via Clerk

Authentication and authorization are the bedrock of user access control. RapidStream has found a reliable partner in Clerk, a robust solution that not only manages these aspects but also enriches the user experience. Clerk handles user authentication, enabling RapidStream to focus on its core competencies.

Clerk’s seamless integration with React frontends has been a game-changer, offering convenient components that harmonize with RapidStream’s customer panel. From effortless user login to session management, Clerk provides the tools needed for a frictionless experience.

Multi-Tenancy with a Twist: Clerk Organizations & Unified Database

One of RapidStream’s features is its ability to host multiple organizations within a single database. This multi-tenancy approach optimizes resource utilization and reduces infrastructure costs. Clerk’s role-based permissions feature dovetails perfectly with this approach, allowing fine-grained control over each organization’s access and actions.

By utilizing Clerk’s webhooks, RapidStream optimizes organization-related actions, such as creation, updates, and deletions. These webhooks, enable seamless adaptation of the internal state within RapidStream’s services.

The Backend Blueprint

Isolation, Security and Scalability

The backend infrastructure reflects RapidStream’s commitment to isolation, security, scalability, and customizability.

Isolation: RapidStream employs a multi-tenant strategy that ensures the separation of data for different organizations. Data schemas are meticulously designed to incorporate the organization’s unique identifier, preventing data collisions.

Security: Despite sharing data within the same database, event store, and cache, RapidStream employs specialized data access techniques. This security measure ensures that data remains confidential and isolated for each organization. Furthermore, maintaining uniform versions and rollouts across all customers guarantees a consistent security posture.

Scalability: RapidStream’s Kubernetes-based deployment model allows independent scaling of services. By monitoring key performance indicators, services can be scaled according to demand. This dynamic approach optimizes resource allocation while providing a seamless experience.

Frontend Flourish: Clerk’s Integration Unleashed

In the frontend realm, RapidStream’s integration of Clerk is joy to work with.

User-Centric Design: RapidStream’s user-focused design ensures effortless user login while refraining from storing user credentials. Users can seamlessly switch between multiple organizations, facilitated by Clerk’s role-based permissions and organization-switching capabilities.

Simplified Session Handling: Clerk takes the reins of session management, freeing RapidStream to concentrate on enhancing user experiences.

Clerk and React - A Seamless Partnership: Clerk’s remarkable integration with React aligns perfectly with RapidStream’s technology stack. The ease of integration, configuration, extension, and usage makes Clerk a natural choice.


RapidStream’s integration of Clerk sets a good example of how technology can be harnessed to create a secure, and user-centric platform. The multi-tenancy approach, fortified by Clerk’s capabilities, paints a picture of an ecosystem where diverse organizations coexist harmoniously while enjoying a seamless user additional event named DefaultValuesSet was introduced, triggered upon OrganizationCreated. In case of replaying the event stream it may happen we create the DefaultValuesSet event several times. You have to consider preventing re-creation of the event (e.g. if the action has important side effects like sending a mail to the user). We decide not to check if the event has already been created. Instead, the services listen for new default value events and check if they already have stored default values. If they do, they skip the event; otherwise, they apply the default values.