SaaS architecture conversations skew to extremes. One camp builds for 100 million users on day one and burns out before they have 100 paying customers. The other camp ships a monolith on a single $5 droplet and discovers data integrity problems at $1M ARR. The right path is neither.

The minimum viable SaaS architecture

• One application server (containerised, auto-scaling).
• One managed Postgres database, with daily snapshots and point-in-time recovery.
• One object store for files and media.
• One CDN in front of static assets.
• A managed queue for async work.
• Structured logging and basic APM from day one.

That is the entire stack. Resist everything else until you can prove you need it.

Multi-tenancy: the decision that follows you for years

Three options:

• Shared schema, tenant_id column. Cheap, fast, the right default for most SaaS.
• Schema-per-tenant. Better isolation, harder to operate. Useful for compliance-heavy SaaS.
• Database-per-tenant. Strongest isolation, highest cost. Required for enterprise SaaS with strict residency rules.

For 80% of SaaS, shared schema with row-level security is the right answer. Do not pre-optimise for "we might need physical isolation someday."

When to add a queue

The moment you have a request that takes more than 2 seconds or could fail and need a retry. Email sending, webhook delivery, report generation, AI calls, file processing — all of these belong in queues, not request handlers.

When to add a cache

When your database load profile shows that 80% of reads hit 20% of rows. Add Redis in front of the hot reads, with sensible TTLs. Avoid caching writes.

When to add a search index

When users start complaining that Postgres full-text search is too slow. Typically around 100K-1M documents. Meilisearch, Typesense and Elasticsearch are all fine — pick the one your team can operate.

When NOT to add Kubernetes

Until you have at least 5 services in production, or are running multi-region. ECS Fargate, Cloud Run and Fly.io give you most of the benefits with a fraction of the operational cost.

Multi-region: the question to ask first

"Do customers complain about latency, or do they need data residency for compliance?" The first is a CDN problem. The second is a real multi-region problem. Treating both the same way wastes a year of engineering.

The observability stack that actually pays off

• Structured logging with request IDs.
• Error tracking (Sentry, Rollbar) — non-negotiable.
• Application performance monitoring (Datadog, New Relic, Honeycomb).
• Uptime monitoring from outside your infrastructure.

The best cloud architecture is the one your on-call engineer can debug at 3 AM on a phone. Optimise for clarity, not cleverness.

Our Cloud Based Software Solution team designs and operates SaaS architectures for companies at every scale — from MVP through enterprise.