Software applications serving multiple customers face a fundamental architectural decision: deploy a separate system for each or share a single instance. While dedicated copies are simpler, maintaining them becomes costly at scale. Consequently, most applications adopt a multi-tenant architecture, where numerous customers, or tenants, share resources like servers and databases.

This sharing, however, introduces significant challenges. The performance of one tenant can negatively impact others, a phenomenon known as the "noisy neighbor problem." A single faulty deployment can affect all tenants simultaneously, and the risk of data leaks, where one tenant accesses another's information, is a critical concern. Multi-tenant systems must actively address these issues.

The article delves into the core concepts of multi-tenancy, exploring various data isolation strategies from shared tables to dedicated databases, each with different cost implications. It examines how the choice between isolation and sharing extends beyond the database to the compute layer and discusses the importance of managing the "blast radius" of failures. Understanding tenant context across the entire system is also crucial for effectively managing these shared environments.