API design for multi-tenant systems: where REST stops scaling

May 17, 2026 · Blog · 4 min read

Scaling a multi-tenant system to accommodate diverse client requirements while maintaining performance and data isolation presents significant API design challenges. Specifically, the need for tenant-specific data filtering, dynamic schema extensions, and efficient subscription models often pushes the boundaries of what RESTful APIs can gracefully handle. While REST excels at resource-oriented interactions, its stateless nature and fixed resource representations can lead to significant over-fetching, under-fetching, and complex client-side logic in multi-tenant environments.

The challenge of tenant-specific data filtering

In a multi-tenant application, different tenants may require varied subsets of data from the same logical resource. For instance, a national registry might expose citizen data, but each government agency (tenant) can only access specific fields or filtered records based on its mandate. A typical REST approach might involve complex query parameters or custom endpoints for each tenant’s needs, leading to:

  • API proliferation: An explosion of endpoints or query parameter combinations, making API discovery and maintenance difficult.
  • Client-side complexity: Clients must understand and construct intricate queries, often leading to brittle integrations.
  • Performance overhead: Over-fetching data and filtering it on the server, or under-fetching and requiring multiple requests.

Consider the contrast between REST and more flexible approaches:

Approach Description Multi-tenant filtering implications
REST (traditional) Fixed resource representations, limited query parameters. Requires custom endpoints or complex query strings per tenant. Can lead to over-fetching.
GraphQL Clients define data requirements in queries. Ideal for tenant-specific data fetching; clients request only what they need. Reduces over/under-fetching.
gRPC Protocol Buffers define strict message structures. Requires careful service design to support diverse tenant queries. Efficient for high-volume, predefined interactions.

For systems like those developed by Softline IT, where a single UnityBase instance might serve multiple government bodies with distinct data access rules, the flexibility to define precise data contracts dynamically is crucial. GraphQL’s ability to allow clients to specify their data requirements in a single request significantly mitigates these issues.

Schema evolution and tenant-specific extensions

Multi-tenant systems often encounter scenarios where different tenants require custom fields or extensions to core data models without impacting other tenants. For example, a tier-1 bank might need specific audit fields for transaction records that a different financial institution tenant does not. Evolving a REST API to support such tenant-specific schema extensions can be cumbersome:

  • Version bloat: Frequent API versioning to accommodate new fields, leading to maintenance nightmares.
  • Polymorphic responses: Using complex JSON structures with optional fields, which can be hard for clients to parse.
  • Database schema challenges: Managing a single database schema that must be flexible enough for all tenants without excessive nulls or performance penalties.

UnityBase’s data modeling capabilities, designed for enterprise-scale systems, address this by allowing flexible object attribute definition and extension. However, exposing these dynamic schemas effectively through an API requires more than just REST’s static resource definitions.

Expert comment
In my experience over 25 years of system implementations, inefficient tenant-specific configuration management via REST APIs leads to increased maintenance complexity and slower client onboarding in 60% of cases, necessitating architectural review for scalability.

Co-founder, Softline IT, Member of the Supervisory Board, Intecracy Group

Real-time updates and subscriptions

Many modern enterprise applications, such as document workflow systems or national registries, require real-time updates for critical events. While REST can simulate real-time with long polling or WebSockets, these are often bolt-on solutions that don’t integrate cleanly with the core API design.

  • Polling overhead: Inefficient for high-frequency updates, especially across numerous tenants.
  • WebSocket complexity: Managing WebSocket connections for each tenant adds significant server-side state and scaling challenges.

GraphQL Subscriptions or gRPC’s streaming capabilities offer more native and efficient mechanisms for real-time data delivery, allowing tenants to subscribe to specific events or data changes without constant polling.

Practical takeaway

While REST remains a robust choice for many scenarios, its limitations become apparent when designing APIs for complex multi-tenant systems that demand fine-grained data control, flexible schema evolution, and efficient real-time updates. For such systems, especially those at national scale like the solutions Softline IT delivers, exploring alternatives like GraphQL or gRPC can provide a more scalable and maintainable foundation. These alternatives offer mechanisms better suited to managing the inherent diversity and dynamic nature of tenant requirements, ultimately reducing client-side complexity and improving API performance.