Designing a Shared Platform to Serve Competing Institutional Clients Without Cross-Contamination

In the SaaS multi-tenancy model, tenants are typically treated as the same entity. However, when competition exists between tenants and the platform operator is also a participant in the same market, a conflict of interest arises that cannot be resolved through simple access control measures. To address this issue, a multi-tiered approach is recommended.

This involves dividing the platform into a core that is blind to tenants, separate extensions for each client, and infrastructure that enforces isolation. By making isolation a tiered versioned feature, it can be discussed in commercial terms rather than being an implicit assumption in the architecture. In production environments, many leaks still occur, such as from logs, dashboards, and caches, rather than from the primary data store.

The challenge of isolation goes beyond simple access control and extends to the contractual and reputational aspects of the platform, as it can lead to significant consequences if sensitive information is revealed between competing clients. RBAC, per-tenant schemas, and network segmentation help prevent unauthorized access, but they are not sufficient to address the more complex problem of legitimate access causing conflicts of interest.

Four failure modes that cannot be solved by tightening access control include aggregate leakage, row-level security limitations, customization that leaks into the core, and operational access as an unmanaged trust boundary. Additionally, shared infrastructure can act as a timing side channel, leading to information leaks through latency and ordering.

To effectively address these issues, isolation should be a primary consideration in the platform's design, rather than an afterthought.