Cloud Architecture for SaaS

The Three Compute Paradigms

Every cloud infrastructure decision ultimately comes down to where your code runs. There are three fundamental models:

In practice, modern SaaS architectures mix all three. Containers for the core API, serverless for event-driven tasks (image processing, email sending, webhook handling), and VMs for ML inference or databases where you need GPU or persistent storage.

Stage 1: MVP Architecture (0 to 1,000 users)

At MVP stage, the architecture should be as simple as possible. The goal is to prove product-market fit, not to build for a million users you do not have yet. Over-engineering at this stage is one of the most common and expensive mistakes startups make.

A sensible MVP architecture:

• Frontend: React or Next.js deployed to Vercel or Cloudflare Pages. Zero infrastructure to manage, global CDN included, free tier is genuinely free at early scale.
• Backend API: A containerized FastAPI or Node.js app on a single managed container service — AWS App Runner, Google Cloud Run, or Railway. Auto-scales from zero and costs nothing when idle.
• Database: Managed PostgreSQL on Supabase, Neon, or PlanetScale. Not self-hosted. Backups and failover are handled for you.
• File storage: AWS S3 or Cloudflare R2. Object storage is cheap ($0.023/GB/month on S3), reliable, and globally accessible.
• Auth: Outsource it. Auth0, Clerk, or Supabase Auth. Implementing auth correctly is complex and not a differentiator.
• Email: Resend or AWS SES. Transactional email is a commodity — do not build your own SMTP server.

This architecture costs effectively nothing until you have paying users, and can handle a few thousand daily active users without modification. The single most important architectural principle at MVP: never build infrastructure that costs money 24/7 for a product that may not find users.

Stage 2: Growth Architecture (1,000 to 100,000 users)

As you grow, bottlenecks emerge. The first is usually the database under heavy read load, followed by the API under concurrent request load, and then media/file handling performance. Each requires a targeted fix:

• Database read replicas — Add read replicas for analytics queries and read-heavy operations. Your write path stays on the primary. This is the single most cost-effective scaling move for a database-heavy SaaS.
• Caching layer — Add Redis (Upstash for serverless, or ElastiCache on AWS) for session data, API response caching, and rate limiting. A cache hit that costs 1ms instead of a 50ms database query pays for itself quickly.
• CDN for user-uploaded content — Put CloudFront or Cloudflare in front of your S3 bucket. Serving images from a CDN edge node instead of S3 directly is dramatically faster for geographically distributed users.
• Async task queue — Move slow operations (PDF generation, email sending, third-party API calls) to a background queue. Redis with Celery (Python), BullMQ (Node), or AWS SQS are all proven choices. The user should not wait for a blocking operation that takes 5 seconds.
• Separate services for distinct scaling needs — If your background job processing and your API are in the same container and the jobs are consuming all the CPU, separate them so you can scale them independently.

Stage 3: Scale Architecture (100,000+ users)

At significant scale, you graduate to operational complexity that requires dedicated platform engineering effort. The patterns:

Multi-Region Deployment

If you have users in India, Europe, and the US, latency to a single-region API becomes a real product problem. Multi-region deployment with a globally distributed database (PlanetScale, CockroachDB, or Postgres with logical replication) and global load balancing (AWS Global Accelerator, Cloudflare) is necessary. This is genuinely complex and should only be tackled when the latency problem is confirmed by user feedback, not anticipated prematurely.

Observability Infrastructure

At scale, you cannot debug production issues manually. You need structured logging (every request logged with correlation IDs), distributed tracing (OpenTelemetry + Jaeger or Honeycomb), and metrics dashboards (Prometheus + Grafana or DataDog). The ability to trace a single user request through every service it touched is essential for diagnosing intermittent issues.

Cost Optimization

At scale, cloud costs become material. Key levers: Reserved Instances or Committed Use Discounts (30-60% savings for stable workloads), Spot Instances for fault-tolerant batch jobs (70-90% cheaper), right-sizing instances to actual usage (CloudWatch metrics usually show most instances are massively over-provisioned), and egress optimization (data leaving the cloud region is often the largest bill line-item — keep your database and API in the same region and use CDN for static assets).

The Managed Service Philosophy

A principle we apply consistently for our clients: use managed services for everything that is not your core differentiation. Running your own PostgreSQL cluster, your own Redis cluster, your own Kafka cluster, or your own Nginx — all of these require operational expertise that takes time away from building your product. Managed alternatives cost slightly more per unit but save enormous engineering time and reduce the blast radius of failures.

The calculation changes only when scale reaches the point where the managed service premium represents a significant fraction of revenue. For most SaaS products, that point is well beyond $100K MRR.

Back to all articles