DevOps for SaaS — ship features, not tickets

What regulates the infrastructure

What actually goes wrong here

• Cross-tenant data exposure from a broken authorisation scope or a missing row-level filter — the defining SaaS failure, because it is a correctness bug rather than an outage, is often invisible in monitoring, and terminates contracts and triggers breach notification in a way that downtime does not
• Noisy-neighbour saturation: one tenant's bulk import, report or API loop consuming shared database connections, queue capacity or IOPS and degrading every other tenant on the same shard
• Schema migrations on large shared tables taking locks that stall the entire tenant population at once — a consequence specifically of pooled multi-tenancy, where there is no way to migrate one customer at a time
• Single-tenant restore from a pooled datastore: backups are taken at cluster level, so recovering one customer's accidentally deleted data without rolling back everyone else's is frequently not supported by the architecture that was chosen for cost
• Identity provider and SSO failures (SAML/OIDC assertion, certificate rotation or IdP outage) locking out an entire enterprise account while the application itself is healthy
• Expired or unrenewed TLS certificates on customer vanity domains and CNAMEs, which fail per-customer and outside the main certificate automation
• Global control-plane changes — a feature flag, config push or entitlement change — applying to all tenants simultaneously, giving a blast radius equal to the whole customer base
• Usage metering and billing pipeline drift silently over- or under-charging customers, discovered at invoice time rather than by availability monitoring

How demand behaves

Multi-tenant and diurnal rather than seasonal: load tracks the working hours of the customer base, so a single-region customer base produces a sharp weekday 09:00-18:00 curve and near-idle weekends, while a global base flattens into a rolling wave across timezones. Superimposed on that are calendar-driven batch spikes — month-end and quarter-end reporting, billing and invoicing runs, and payroll or fiscal-period closes for finance-adjacent products — plus one-off surges from large customer onboarding and data migrations.

Data you will be holding

The vendor typically acts as a processor under GDPR for its customers' business data, which pulls in named-subprocessor disclosure, data-residency commitments, international transfer mechanisms, and contractual deletion-or-return duties on termination. The practical infrastructure consequence is that the region a workload runs in, and the identity of every downstream provider in the chain, become contractual terms rather than engineering choices.

Architecture this pushes you toward

The central design tension is pooled versus siloed tenancy: shared databases and clusters give the unit economics the business model depends on, but concentrate blast radius and make per-tenant residency, restore and rate-limiting hard. Region pinning is driven by contractual residency commitments rather than latency, which pushes vendors toward multiple regional deployments of the same stack with a shared or replicated control plane. Progressive delivery — feature flags, tenant-ring or canary rollouts and blue/green deploys — is the standard mitigation for the fact that one deployment reaches every customer at once.

Availability expectation

Enterprise agreements commonly commit to 99.9% monthly availability (about 43 minutes of downtime per month) with service credits as the sole remedy; higher-priced tiers commonly commit to 99.95%. These are contractual norms, not a regulatory floor, and definitions of 'available' and of excluded maintenance windows vary widely between vendors.