Sharded Hub-and-Spoke Architecture Mitigates 'Noisy Neighbor' Issues in Multi-Tenant Platforms

The Challenge of Multi-Tenant Environments

Multi-tenant platforms, whether SaaS providers or internal data platforms, face the 'noisy neighbor' problem. A single tenant experiencing a data burst or a database failure can cause system-wide performance issues, leading to backlogs and Service Level Agreement (SLA) violations across critical data pipelines.

Limitations of Monolithic Architectures

Traditional monolithic architectures process data for all tenants through a single, unified stream. This design means that a performance issue with one tenant's database instance creates back pressure, degrading performance for all other tenants on the platform. This results in a 100% blast radius for failures, inefficient scaling due to worst-case provisioning, and unstable SLAs.

The Sharded Hub-and-Spoke Solution

To address these issues, a sharded hub-and-spoke architecture decouples processing. The 'hub' acts as a router, while 'spokes' provide isolated execution environments. This pattern enhances platform resilience and ensures more consistent performance.

Components of the Architecture

The architecture consists of three main components. The 'hub' is a lightweight Dataflow job that routes data by parsing tenant IDs or business domains and fanning data out to isolated buffers. Pub/Sub topics serve as 'buffers' between the hub and spokes, providing durable isolation and preventing slow downstream sinks from backing up the source. Finally, 'spokes' are multiple, smaller Dataflow instances categorized by workload, such as dedicated pipelines for high-priority tenants, grouped pipelines for smaller tenants, or specialized pipelines for complex business logic.