Himanshu Kukreja
0%
LearnSystem DesignWeek 9Multi Tanency Security Preview
Week Preview

Week 9 Preview: Multi-Tenancy, Security, and Compliance

System Design Mastery Series

Welcome to Week 9

Theme: Building Systems for the Real World

For the past eight weeks, we've focused on making systems that work — scalable, reliable, and fast. But there's a dimension we've only touched on: making systems that are safe to operate in a regulated world.

THE ENTERPRISE REALITY CHECK

Your startup just landed its first enterprise customer.
They send over their security questionnaire:

"How do you isolate our data from other customers?"
"Where is our data stored geographically?"
"Can you provide SOC 2 Type II certification?"
"How do you handle GDPR deletion requests?"
"What's your encryption strategy at rest and in transit?"
"How do you prevent one customer from affecting another's performance?"

You realize your beautiful microservices architecture
has a massive gap: you built for scale, not for trust.

Week 9 fills that gap.

What You'll Learn This Week

The Big Picture

WEEK 9: ENTERPRISE-READY SYSTEMS

Day 1: Tenant Isolation Strategies
       "How do I serve 1000 customers without them seeing each other's data?"

Day 2: Noisy Neighbor Prevention  
       "How do I stop one customer from ruining everyone else's experience?"

Day 3: Data Residency and GDPR
       "How do I keep EU data in the EU while running a global platform?"

Day 4: Right to Deletion
       "How do I delete a user's data when it's in 47 different systems?"

Day 5: Security Architecture
       "How do I build defense in depth for a multi-tenant system?"

Capstone: Design a GDPR-Compliant Multi-Tenant SaaS Platform
          A complete B2B SaaS system with enterprise security requirements

Day-by-Day Breakdown

Day 1: Tenant Isolation Strategies

The Core Question: How do you serve thousands of customers on shared infrastructure while guaranteeing they can't see each other's data?

ISOLATION SPECTRUM

Shared Everything ─────────────────────────────── Dedicated Everything
        │                                                    │
   Low Cost                                            High Cost
   Low Isolation                                       High Isolation
   High Density                                        Low Density

┌─────────────┬─────────────┬─────────────┬─────────────┬─────────────┐
│   Shared    │   Shared    │   Schema    │  Database   │   Fully     │
│   Tables    │   Database  │     per     │     per     │   Isolated  │
│   (Row-     │   (Logical  │   Tenant    │   Tenant    │   (VPC per  │
│   level)    │   isolation)│             │             │   tenant)   │
└─────────────┴─────────────┴─────────────┴─────────────┴─────────────┘
      │              │              │              │              │
   Startups     Mid-market     Growing        Enterprise    Regulated
   SMB          SaaS           Enterprise                   Industries

What You'll Build:

  • Tenant context propagation across services
  • Row-level security implementation
  • Schema-per-tenant database architecture
  • Tenant routing and request isolation

Key Trade-offs:

  • Cost vs isolation level
  • Operational complexity vs security guarantees
  • Performance vs resource sharing

Day 2: Noisy Neighbor Prevention

The Core Question: How do you stop one customer from consuming all resources and degrading service for everyone else?

THE NOISY NEIGHBOR PROBLEM

Tenant A: Normal usage
          ████░░░░░░ 40% of their quota

Tenant B: Normal usage  
          ██████░░░░ 60% of their quota

Tenant C: RUNAWAY QUERY
          ████████████████████████████████ 800% of quota!
          └── Running analytics on 10M rows
          └── Consuming all database CPU
          └── Everyone else is slow

Without protection:
├── Tenant A: Queries timeout
├── Tenant B: Requests fail
├── Support tickets flood in
└── You lose customers

With noisy neighbor prevention:
├── Tenant C: Throttled to quota
├── Tenant A: Normal performance
├── Tenant B: Normal performance
└── Tenant C: Gets notification about limits

What You'll Build:

  • Per-tenant rate limiting
  • Resource quota management
  • Fair scheduling algorithms
  • Tenant usage dashboards

Key Techniques:

  • Token bucket per tenant
  • CPU and memory quotas
  • Query complexity analysis
  • Graceful degradation

Day 3: Data Residency and GDPR

The Core Question: How do you run a global platform while keeping data in the regions where it legally must stay?

DATA RESIDENCY REQUIREMENTS

GDPR (European Union):
├── Personal data of EU residents must be protected
├── Transfers outside EU require legal basis
├── Data Processing Agreements required
└── Fines: Up to 4% of global revenue

Data Localization Laws:
├── Russia: Personal data must be stored in Russia
├── China: Critical data must stay in China
├── India: Payment data must be stored locally
├── Brazil: LGPD has GDPR-like requirements
└── Many more emerging...

YOUR CHALLENGE:
┌───────────────────────────────────────────────────────────────┐
│                                                               │
│  Single Global Platform                                       │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │  User in Germany → Data must stay in EU                 │  │
│  │  User in California → CCPA applies                      │  │
│  │  User in Brazil → LGPD applies                          │  │
│  │  Analytics team in US → Needs access to all data?       │  │
│  └─────────────────────────────────────────────────────────┘  │
│                                                               │
│  How do you architect this?                                   │
│                                                               │
└───────────────────────────────────────────────────────────────┘

What You'll Build:

  • Regional data partitioning
  • Cross-region data access controls
  • Consent management system
  • Data Processing Agreement tracking

Key Concepts:

  • Data residency vs data sovereignty
  • Standard Contractual Clauses
  • Privacy by design
  • Lawful basis for processing

Day 4: Right to Deletion (GDPR Article 17)

The Core Question: When a user says "delete all my data," how do you actually do it across dozens of systems?

THE DELETION NIGHTMARE

User requests deletion. Their data exists in:

├── PostgreSQL (primary database)
│   ├── users table
│   ├── orders table
│   ├── preferences table
│   └── activity_log table
│
├── Elasticsearch (search index)
│   └── user_documents index
│
├── Redis (cache)
│   ├── session data
│   └── computed preferences
│
├── Kafka (event stream)
│   └── Events with user_id in payload
│
├── S3 (file storage)
│   ├── profile_photos/
│   └── uploaded_documents/
│
├── Analytics Warehouse (BigQuery)
│   ├── fact_events
│   └── dim_users
│
├── Backups
│   ├── Daily PostgreSQL backups (90 days)
│   ├── S3 versioned objects
│   └── Point-in-time recovery logs
│
├── Third-party services
│   ├── Stripe (payment data)
│   ├── SendGrid (email logs)
│   ├── Intercom (support history)
│   └── Amplitude (analytics)
│
└── Machine Learning
    ├── Training datasets
    └── Model weights (derived from user data?)

GDPR says: 30 days to complete deletion
Reality: This is really, really hard

What You'll Build:

  • Deletion request workflow
  • Data inventory and mapping
  • Cascading deletion across systems
  • Deletion verification and audit

Key Challenges:

  • Backups and point-in-time recovery
  • Aggregated vs individual data
  • Third-party data processors
  • Proving deletion happened

Day 5: Security Architecture

The Core Question: How do you build defense in depth for a system where one breach could expose thousands of customers' data?

MULTI-TENANT SECURITY LAYERS

Layer 1: NETWORK
├── VPC isolation
├── Security groups
├── Web Application Firewall
└── DDoS protection

Layer 2: IDENTITY
├── Authentication (who are you?)
├── Authorization (what can you access?)
├── Tenant context (which tenant are you acting for?)
└── Service-to-service auth

Layer 3: APPLICATION
├── Input validation
├── Output encoding
├── Tenant isolation enforcement
└── Audit logging

Layer 4: DATA
├── Encryption at rest
├── Encryption in transit
├── Key management
└── Data masking

Layer 5: DETECTION
├── Intrusion detection
├── Anomaly detection
├── PII leak detection in logs
└── Security monitoring

ZERO TRUST PRINCIPLE:
"Never trust, always verify"
├── Every request must be authenticated
├── Every request must be authorized
├── Assume the network is compromised
└── Minimize blast radius

What You'll Build:

  • Service mesh security policies
  • Secrets management
  • Audit logging infrastructure
  • PII detection and masking

Key Patterns:

  • Defense in depth
  • Least privilege access
  • Separation of duties
  • Fail secure (not fail open)

The Capstone: GDPR-Compliant Multi-Tenant SaaS Platform

At the end of Week 9, you'll design a complete B2B SaaS platform that could pass an enterprise security audit.

CAPSTONE SCENARIO

You're designing a B2B SaaS platform for HR management:
├── 500 enterprise customers
├── 2 million total users
├── Highly sensitive data (employee PII, salaries, performance reviews)
├── Customers in US, EU, UK, Australia
├── SOC 2 Type II required
├── GDPR and CCPA compliance required

Requirements:
1. Multi-tenant with enterprise isolation option
2. Data residency (EU data stays in EU)
3. Complete deletion within 30 days
4. Audit logs for all data access
5. Encryption everywhere
6. Noisy neighbor prevention

Design the complete architecture.

This capstone will test your ability to combine:

  • Tenant isolation strategies (Day 1)
  • Resource management (Day 2)
  • Data residency (Day 3)
  • Deletion workflows (Day 4)
  • Security architecture (Day 5)

Key Concepts to Master

Multi-Tenancy Patterns

Pattern Isolation Cost Complexity Use Case
Shared tables Low Lowest Low Early-stage SaaS
Row-level security Medium Low Medium SMB SaaS
Schema per tenant High Medium Medium Mid-market
Database per tenant Very High High High Enterprise
VPC per tenant Highest Highest Highest Regulated

Compliance Framework

COMPLIANCE REQUIREMENTS MAP

GDPR (EU):
├── Lawful basis for processing
├── Data minimization
├── Right to access (Article 15)
├── Right to deletion (Article 17)
├── Data portability (Article 20)
├── Breach notification (72 hours)
└── Data Protection Officer

SOC 2:
├── Security (required)
├── Availability (optional)
├── Processing Integrity (optional)
├── Confidentiality (optional)
└── Privacy (optional)

HIPAA (Healthcare):
├── PHI protection
├── Access controls
├── Audit trails
├── Encryption requirements
└── Business Associate Agreements

PCI DSS (Payments):
├── Network segmentation
├── Encryption of card data
├── Access logging
├── Vulnerability management
└── Annual audits

Security Principles

DEFENSE IN DEPTH

External Request
      │
      ▼
┌─────────────────┐
│  WAF / DDoS     │ ← Layer 1: Perimeter
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  API Gateway    │ ← Layer 2: Edge
│  Rate Limiting  │
│  Auth Check     │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  Service Mesh   │ ← Layer 3: Service
│  mTLS           │
│  Authorization  │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  Application    │ ← Layer 4: Application
│  Input Valid.   │
│  Tenant Check   │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  Database       │ ← Layer 5: Data
│  Encryption     │
│  Row-level Sec  │
└─────────────────┘

Each layer assumes the previous layer failed.

Technologies You'll Work With

Identity and Access Management

IDENTITY STACK

Authentication:
├── OAuth 2.0 / OpenID Connect
├── SAML (enterprise SSO)
├── Multi-factor authentication
└── Session management

Authorization:
├── RBAC (Role-Based Access Control)
├── ABAC (Attribute-Based Access Control)
├── Policy engines (OPA, Cedar)
└── Tenant-scoped permissions

Secrets Management:
├── HashiCorp Vault
├── AWS Secrets Manager
├── Azure Key Vault
└── Kubernetes Secrets (encrypted)

Compliance Tooling

COMPLIANCE AND SECURITY TOOLS

Data Discovery:
├── AWS Macie (PII detection)
├── Google Cloud DLP
├── Custom scanning pipelines

Audit Logging:
├── AWS CloudTrail
├── Audit log databases
├── SIEM integration (Splunk, Datadog)

Encryption:
├── AWS KMS / Cloud KMS
├── Application-level encryption
├── Database Transparent Encryption

Policy Enforcement:
├── Open Policy Agent (OPA)
├── AWS Organizations SCPs
├── Terraform Sentinel

Real-World Case Studies

Throughout the week, we'll examine:

Slack's Multi-Tenancy

SLACK ARCHITECTURE

Challenge:
├── Thousands of enterprise customers
├── Strict data isolation required
├── Real-time messaging at scale
├── Enterprise Key Management

Solution:
├── Logical isolation with strict tenant context
├── Slack Connect (controlled cross-tenant messaging)
├── Enterprise Key Management (customer-controlled keys)
└── Channel-based data partitioning

Stripe's Compliance

STRIPE SECURITY MODEL

Challenge:
├── PCI DSS Level 1 (highest level)
├── Multi-region operations
├── API-first platform
├── Developer experience

Solution:
├── Network segmentation (cardholder data isolated)
├── Token-based approach (minimize PCI scope)
├── Transparent encryption everywhere
├── Extensive audit logging
└── Security as a feature

Salesforce Multi-Tenancy

SALESFORCE ARCHITECTURE

Challenge:
├── 150K+ customers on shared infrastructure
├── Enterprise isolation requirements
├── Custom objects and fields per tenant
├── Performance at scale

Solution:
├── Shared database with organization ID
├── Metadata-driven customization
├── Governor limits (strict resource quotas)
├── Trust.salesforce.com (transparency)
└── Shield (additional security for enterprises)

How Week 9 Connects to Previous Weeks

BUILDING ON PRIOR KNOWLEDGE

Week 1 (Storage):
└── Now: Tenant-aware partitioning, encrypted storage

Week 2 (Failure Handling):
└── Now: Security-aware circuit breakers, audit on failures

Week 3 (Messaging):
└── Now: Tenant isolation in queues, PII in event payloads

Week 4 (Caching):
└── Now: Tenant-scoped caches, cache invalidation on deletion

Week 5 (Consistency):
└── Now: Consistency in deletion workflows

Week 6 (Notifications):
└── Now: Consent-based notifications, GDPR-compliant

Week 7 (Search):
└── Now: Tenant-isolated search indexes, data residency

Week 8 (Analytics):
└── Now: Privacy-preserving analytics, deletion from warehouse

What Success Looks Like

By the end of Week 9, you should be able to:

WEEK 9 COMPETENCIES

MULTI-TENANCY:
├── Design isolation strategy matching business needs
├── Implement row-level security
├── Build tenant context propagation
└── Handle tenant onboarding and offboarding

RESOURCE MANAGEMENT:
├── Implement per-tenant quotas
├── Build fair scheduling systems
├── Design noisy neighbor detection
└── Create tenant usage dashboards

COMPLIANCE:
├── Design for data residency requirements
├── Implement deletion workflows
├── Build consent management systems
└── Create audit trails

SECURITY:
├── Apply defense in depth
├── Design secrets management
├── Implement encryption strategies
└── Build security monitoring

INTERVIEW SKILLS:
├── Discuss compliance trade-offs confidently
├── Draw security architecture diagrams
├── Explain isolation levels clearly
└── Handle "what about GDPR?" questions

Interview Relevance

Week 9 topics are increasingly common in system design interviews:

INTERVIEW SCENARIOS

"Design a multi-tenant SaaS platform"
├── Tenant isolation is the first thing to discuss
├── Noisy neighbor is a likely follow-up
└── Security questions are almost guaranteed

"Design a system that handles user data"
├── GDPR deletion is fair game
├── Data residency may come up for global systems
└── Encryption requirements expected

"You mentioned storing PII..."
├── Interviewers will probe on security
├── Compliance awareness shows maturity
└── Trade-off discussions valued

WHY THIS MATTERS:
├── Shows you can build enterprise-ready systems
├── Demonstrates awareness of real-world constraints
├── Differentiates you from candidates who only know scale
└── Especially important for B2B/enterprise roles

Preparing for Week 9

Prerequisites

Make sure you're comfortable with:

  • Database design (Week 1)
  • API design patterns
  • Authentication basics (OAuth, JWT)
  • Basic encryption concepts

Mindset Shift

FROM WEEK 8 TO WEEK 9

Week 8 (Analytics):
├── Focus: Performance and scale
├── Question: "How do we make it fast?"
└── Metric: Latency, throughput

Week 9 (Security/Compliance):
├── Focus: Trust and safety
├── Question: "How do we make it secure?"
└── Metric: Isolation, compliance, audit coverage

The engineering is different:
├── Performance: Optimize the common case
├── Security: Protect against the worst case
├── Performance: Failures are acceptable (retry)
├── Security: Failures are catastrophic (breach)

Resources to Explore

Before Starting

  • GDPR Overview: gdpr.eu
  • OWASP Top 10: owasp.org
  • SOC 2 Basics: Research the five trust principles

During the Week

  • AWS Multi-Tenancy Whitepaper
  • Slack's Enterprise Security Documentation
  • Stripe's Security Documentation

Optional Deep Dives

  • "Building Secure and Reliable Systems" (Google SRE Book)
  • HashiCorp Vault Documentation
  • Open Policy Agent Documentation

Summary

WEEK 9 AT A GLANCE

Theme: Enterprise-Ready Systems

Day 1: TENANT ISOLATION
       Shared vs dedicated, row-level security, schema separation

Day 2: NOISY NEIGHBOR
       Quotas, rate limiting, fair scheduling, usage tracking

Day 3: DATA RESIDENCY  
       GDPR, regional data, cross-border transfers, consent

Day 4: RIGHT TO DELETION
       Deletion workflows, data inventory, verification, audit

Day 5: SECURITY ARCHITECTURE
       Defense in depth, zero trust, encryption, monitoring

Capstone: GDPR-COMPLIANT MULTI-TENANT SAAS
          Complete B2B platform with enterprise security

The week that makes your systems enterprise-ready.

Week 9 begins tomorrow with Day 1: Tenant Isolation Strategies

Your systems have been fast. Now let's make them trusted.

Back to Course Overview