Release date: August 9, 2025
Tenant isolation
Who is impacted?
Tenant | Impact (Yes/No) |
OHID | Yes (with outage) |
MAHIX | Yes (with outage) |
BEWELLNM | Yes (with outage) |
GOVID | Yes (with outage) |
HSID | No impact |
What changed?
We introduced Multi-region Tenant Isolation on the Aikyam platform. In general , multi-region tenant isolation in a multi-tenant architecture ensures that each tenant (customer) within a shared application environment has their data and resources both physically and logically segregated across various geographic regions. The approach improved data residency, strengthened disaster recovery, and supported compliance, while still allowing tenants to benefit from shared infrastructure efficiencies.
Why?
Limit blast radius
Limiting the blast radius referred to designing systems or processes in a way that contained failures or issues within a small, well-defined area, minimizing their effect on the overall system. By doing so, organizations ensured that if something went wrong during a deployment or rollout, only a small segment of users or services was affected rather than the entire platform.
Strategies to limit the blast radius included deploying changes to a subset of servers or regions first, using feature flags to turn features on or off for select user groups, and monitoring early signals before a wider release. This not only helped catch issues quickly but also facilitated safer, more gradual rollouts, fostering resilience and reliability within the platform.
Addressing the noisy neighbor
The “noisy neighbor” problem referred to a scenario where one tenant’s high resource usage negatively impacted other tenants sharing the same infrastructure. This often manifested as performance degradation, increased latency, or even service disruptions for affected tenants. Effective management of this issue was crucial in multi-tenant environments.