The Lessons from enabling search for multitenant applications:

Multitenant search solutions provide search capabilities to any number of tenants who cannot see or share data of any other tenant. Searching often requires content virtualization across different sources where the content can be considered a shared resource. Providing content isolation with search capabilities is the topic of this article.

A search service usually builds an index of the content so that the queries for the content can return results efficiently since the index is far easier and efficient to lookup than traversing the entire content store. The search service can be considered equivalent to a database service and indeed search can be provided out of box from a database. All the multitenant considerations for database services hold for the search service as well. Each index within a search service has its own schema, which is defined by several customizable fields. Search services, indexes, fields and documents are infrastructure and there is little or no user control. A search service can enable tenant isolation via one of the following three methods.

The application developer consumes one or more search services and divide their tenants among services, indexes or both. The methods to provide tenant isolation, scale, cost efficiency, ease of operations and reduced footprint have the following patterns:

1.       One index per tenant: This pattern has an index dedicated to a tenant within a search service that is shared with other tenants.

2.       One service per tenant: This pattern has its own dedicated service offering the highest levels of data and workload separation.

3.       A mix of both: Larger more active tenants are assigned dedicated services and the smaller ones are assigned individual indexes within the shared services.

In an index-per-tenant model, tenants achieve data isolation because all search requests and document operations are issued at an index level. The application layer directs tenant traffic to proper indexes while managing the resources at the service levels across all tenants. This model is simple for the application developers and allows them to oversubscribe the capacity among the application’s tenants. The tradeoff is the restrictions to handle peak load where most or all of the tenants are highly active. The index per tenant model provides the basis for a variable cost model. It may not be the most efficient for an application with a global footprint.

In the service-per-tenant model, each tenant has its own search service. In this model, each application achieves a maximum level of isolation for its tenants. Each service has dedicated storage and throughput for handling search request as well as separate API keys. This pattern is effective when each tenant has a large footprint, or the workload has little variability from tenant to tenant since resources are not shared.

With the mix for both index-per-tenant and service-per-tenant strategies, an application’s largest tenants can occupy dedicated services while the numerous less active, smaller tenants can occupy indexes in a shared service. It ensures that the largest tenants can derive high performance from the service, while protecting the smaller tenants from noisy neighbors. There is some planning required to classify tenants into those that required dedicated and those that can leverage a shared service.

The above patterns assume a uniform scope where each tenant is a whole instance of an application but they can handle many smaller scopes. If the service per tenant and index per tenant are not sufficiently small scopes, then the index can be utilized for a finer degree of granularity. A field can be added to an index to make it behave differently to different client endpoints. This helps to achieve separate user accounts, separate permission levels, and even completely separate applications.

Reference: https://1drv.ms/w/s!Ashlm-Nw-wnWhLMfc6pdJbQZ6XiPWA?e=fBoKcN