Designing Multi-Tenant IoT Platforms
Multi-tenancy is an isolation problem before it's a scaling problem. A tour of tenancy models, data boundaries, and the blast radius you're really designing around.
Multi-tenancy is usually framed as a cost-efficiency story: share infrastructure, serve many customers, scale gracefully. That framing is incomplete. Tenancy is first and foremost an isolation problem — the question isn’t “how do we share?” but “what must never leak, and what’s the blast radius when something does?”
This is a placeholder article. The outline below maps the decision space.
Start from the isolation requirement, not the efficiency goal
Decide what isolation each tenant actually requires before you choose an architecture. The answer dictates everything downstream — data boundaries, key management, even your incident runbook.
The tenancy spectrum
- Pooled — shared infrastructure, tenant ID on every row. Efficient, but isolation rests entirely on flawless authorization.
- Siloed — dedicated resources per tenant. Strong isolation, higher cost and operational surface.
- Bridge models — pooled compute, siloed data; or pooled by default with siloed tiers for tenants who require it.
Most platforms land on a bridge model and regret pretending they could stay purely pooled.
Data boundaries that hold
- Enforce tenant scoping at the lowest layer you can, not just in application code.
- Make cross-tenant access structurally impossible, not merely discouraged.
- Encrypt per tenant where it matters, and design key rotation alongside it.
Blast radius is the real design variable
Every tenancy decision is a bet on what happens when something goes wrong. A noisy-neighbor incident, a bad deploy, a leaked credential — design so the damage is contained to one tenant, and so you can prove it afterward.
Operational reality
Multi-tenancy you can’t observe per tenant is multi-tenancy you can’t operate. Build per-tenant metrics, quotas, and audit from the start — retrofitting them is its own migration project.