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.
Built for scale, not for trust
Q1/2 Your microservices platform handles 10x traffic spikes flawlessly. Why might it still fail an enterprise security questionnaire?
Answer & explanation
Answer: C
The questionnaire asks about trust: data isolation, where data lives, GDPR deletion, encryption and certifications. A system can be fast and reliable yet still have no answer for any of those, which is the gap Week 9 fills.
Q2/2 One questionnaire item asks "How do you prevent one customer from affecting another's performance?" What kind of isolation is that about?
Answer & explanation
Answer: B
It is about shared resources, not data visibility: one tenant's heavy usage slowing down everyone else. Tenants can be perfectly separated at the data level and still hurt each other through shared CPU, connections or queues.
An enterprise security questionnaire asks about isolation, data location, SOC 2, GDPR deletion, encryption and noisy neighbours: a system built for scale is not yet built for trust, and security must protect against the worst case. The week covers the tenant isolation spectrum from shared tables to a VPC per tenant, throttling a tenant at 800% of its quota, keeping EU data in the EU, deleting one user's data from every system, and five layers of defence in depth. The capstone combines them in a document management platform for 500 enterprise tenants in the US, EU and APAC, with six requirements from a dedicated enterprise tier to deletion within 30 days.
What You'll Learn This Week#
The Big Picture#
- 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?
Shared Everything (Low Cost · Low Isolation · High Density) ⟶ Dedicated Everything (High Cost · High Isolation · Low Density)
| Model | Typical customers |
|---|---|
| Shared Tables (Row-level) | Startups, SMB |
| Shared Database (Logical isolation) | Mid-market SaaS |
| Schema per Tenant | Growing Enterprise |
| Database per Tenant | Enterprise |
| Fully Isolated (VPC per tenant) | Regulated 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?
| Tenant | Usage | Quota used |
|---|---|---|
| Tenant A | Normal usage | 40% of their quota |
| Tenant B | Normal usage | 60% of their quota |
| Tenant C | RUNAWAY QUERY | 800% of quota! |
Tenant C:
- 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?
GDPR (European Union)
- Personal data of EU residents must be protected
- Transfers outside EU require legal basis
- Data Processing Agreements required
- Fines: Up to €20M or 4% of global annual turnover, whichever is higher
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?
User requests deletion. Their data exists in:
PostgreSQL — primary database
userstableorderstablepreferencestableactivity_logtable
Elasticsearch — search index
user_documentsindex
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_eventsdim_users
Backups
- PostgreSQL backups (daily kept 30 days, weekly kept 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: respond within one month (extendable by two more months for complex requests)
- 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?
| Layer | Controls |
|---|---|
| 1. PERIMETER | Web Application Firewall · DDoS protection · Rate limiting · IP allowlisting for admin |
| 2. NETWORK | VPC isolation · Security groups · Private subnets for databases · Network ACLs |
| 3. APPLICATION | Authentication (who are you?) · Authorization (what can you access?) · Tenant context (which tenant are you acting for?) · Input validation · Output encoding |
| 4. DATA | Encryption at rest · Encryption in transit · Key management · Data masking |
| 5. MONITORING | Audit logging · Intrusion detection · Anomaly detection · PII leak detection in logs |
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.
You're designing a B2B SaaS platform for enterprise document management. Companies store, search, share and audit their contracts, policies and reports:
- 500 enterprise customers (tenants), growing to 2,000
- Largest tenant: 50,000 users and 10M documents; smallest: 50 users and 10K documents
- About 100M documents (50TB), growing 20% a year
- 1,000 requests a second at peak, 60% of them searches
- Customers in the US, EU and APAC, some in regulated industries (healthcare, finance)
- SOC 2 Type II controls and a HIPAA-ready architecture
Requirements
- Multi-tenant on shared infrastructure, with a dedicated enterprise tier
- Data residency (EU document content and metadata stay in the EU)
- GDPR deletion within 30 days, plus data export
- Audit logs for all data access
- Encryption everywhere
- 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#
- 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#
%% title: Defense in depth
flowchart TD
R@{ icon: "sd:user", label: "External Request" } --> L1@{ icon: "sd:firewall", label: "WAF · DDoS · Rate Limiting<br/>Layer 1: Perimeter" }
L1 --> L2@{ icon: "sd:network", label: "VPC · Security Groups · Private Subnets<br/>Layer 2: Network" }
L2 --> L3["AuthN · AuthZ · Input Valid. · Tenant Check<br/>Layer 3: Application"]:::core
L3 --> L4@{ icon: "sd:database", label: "Encryption · Row-level Sec<br/>Layer 4: Data" }
L5@{ icon: "sd:log", label: "Audit Logs · Anomaly Detection<br/>Layer 5: Monitoring" }
L1 -.-> L5
L2 -.-> L5
L3 -.-> L5
L4 -.-> L5
class R client
class L1 edge
class L2 service
class L4 storeEach layer assumes the others might fail.
Technologies You'll Work With#
Identity and Access Management#
- 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 — base64 only; enable encryption at rest
Compliance Tooling#
- 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#
Challenge
- Many 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#
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#
Challenge
- A very large customer base 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#
| Week | Now |
|---|---|
| Week 1 (Storage) | Tenant-aware partitioning, encrypted storage |
| Week 2 (Failure Handling) | Security-aware circuit breakers, audit on failures |
| Week 3 (Messaging) | Tenant isolation in queues, PII in event payloads |
| Week 4 (Caching) | Tenant-scoped caches, cache invalidation on deletion |
| Week 5 (Consistency) | Consistency in deletion workflows |
| Week 6 (Notifications) | Consent-based notifications, GDPR-compliant |
| Week 7 (Search) | Tenant-isolated search indexes, data residency |
| Week 8 (Analytics) | Privacy-preserving analytics, deletion from warehouse |
What Success Looks Like#
By the end of Week 9, you should be able to:
- 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:
"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#
| Week 8 (Analytics) | Week 9 (Security/Compliance) | |
|---|---|---|
| Focus | Performance and scale | Trust and safety |
| Question | "How do we make it fast?" | "How do we make it secure?" |
| Metric | Latency, throughput | 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#
- Read
GDPR Overview: gdpr.eu
- Read
OWASP Top 10: owasp.org
- Read
SOC 2 Basics: Research the five trust principles
During the Week#
- Paper
AWS Multi-Tenancy Whitepaper
- Docs
Slack's Enterprise Security Documentation
- Docs
Stripe's Security Documentation
Optional Deep Dives#
- Book
"Building Secure and Reliable Systems" (Google SRE Book)
- Docs
HashiCorp Vault Documentation
- Docs
Open Policy Agent Documentation
Summary#
- 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.
this lesson in shorts · 1
play them all →One idea from this lesson in about a minute each, made for your phone.
New lessons by email
New lessons, side quests and case files as they ship, at most once a week. No spam, unsubscribe anytime.
Discussion · …
Public: everyone reading this lesson sees comments. Be kind and keep it on the material.
