---
title: "Multi-tenant architecture | Skills We Assign For | Azendo"
description: "Multi-tenant architecture — isolation models, noisy neighbours, plus the Azendo roles assigned for it."
url: "https://azendo.co/skills/multi-tenant-architecture/"
---

[Skills](https://azendo.co/skills/) Architecture and patterns 

# Multi-tenant architecture.

Multi-tenant architecture serves several customers from shared infrastructure while keeping their data isolated, through shared schemas with tenant identifiers, separate schemas, or separate databases per tenant.

## Where Multi-tenant architecture fits on a long engagement.

The isolation model is the decision everything else follows from. A shared schema with a tenant column is cheapest to operate and puts isolation entirely in application code, where one missing filter is a data breach. Separate databases isolate properly and multiply operational cost. Neither is right in general.

Enforcing isolation in one place is what makes the shared model survivable. Row-level security in the database, or a query layer that cannot construct an unfiltered query, means isolation does not depend on every developer remembering — which they will not.

## What an assigned team does with Multi-tenant architecture.

Noisy neighbours are the operational problem. One tenant running an expensive report degrades the experience for everyone on shared infrastructure, and without per-tenant limits there is no mechanism to prevent it.

Designing those controls before a large customer arrives is considerably easier than retrofitting them during an incident, and it is part of the architectural work scoped under [software development outsourcing](https://azendo.co/services/software-development/).

## What we use Multi-tenant architecture for.

* Isolation enforced structurally Row-level security or a query layer, so it does not depend on developer memory.
* Per-tenant limits Resource controls, so one customer cannot degrade everyone else.
* A model chosen for the actual requirements Shared or separate decided from compliance and cost rather than by default.

## How Multi-tenant architecture capacity is assigned.

Multi-tenant design is assigned inside application capacity, with isolation enforced at the data layer rather than in application logic.

## Industries that ask for it

* [SaaS and technology](https://azendo.co/industries/saas-and-technology/)

## Related in architecture and patterns

* [CQRS — skill we assign for](https://azendo.co/skills/cqrs/)
* [Domain-driven design — skill we assign for](https://azendo.co/skills/domain-driven-design/)
* [event-driven architecture — skill we assign for](https://azendo.co/skills/event-driven-architecture/)
* [microservices and modular monoliths — skill we assign for](https://azendo.co/skills/microservices-and-modular-monoliths/)
* [AWS and Azure reference architectures — skill we assign for](https://azendo.co/skills/aws-and-azure-reference-architectures/)
* [Double-entry ledgers — skill we assign for](https://azendo.co/skills/double-entry-ledgers/)

## Tell us what your roadmap needs Multi-tenant architecture for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)