Skip to content
Back to case studies
SanitizedCloud Architecture2024

SaaS Platform Arch

ClickOps + slow environments blocking ship → 99.9% availability, 40% AWS cut, envs in minutes.

Role
Lead Platform Engineer
Context
Developer Tools SaaS
Duration
6 months
Team
3 engineers + 1 architect (me)

Tech stack

  • Python
  • Lambda
  • API Gateway
  • DynamoDB
  • Celery
  • Terraform
  • React
  • Docker
  • Kubernetes
Executive summary

Business problem and production context.

Business problem

The platform needed to scale from pilot to production-grade with minimal operational overhead. Build operations were slow, monitoring was non-existent, and infrastructure was manually provisioned, slowing feature delivery to a crawl.

Architecture decision

Designed a fully serverless architecture using Python, Lambda, API Gateway, and DynamoDB. Implemented Celery-based task queues with SQS for async build operations and deployment coordination. Built React/TypeScript dashboards for real-time system monitoring.

awsAWS Account / ProdigyBuildRequestResponseTENANT INGRESSPROVISIONING + APITENANT DATA + IDENTITY12345678Route 53tenant subdomainsCloudFrontedge + WAFAPI GatewayCognito JWTLambdaAPI handlersStep Functionsenv provisioningECS Fargatebackground jobsRDS Aurorarow-level tenant IDS3per-tenant prefixCognitouser poolsCROSS-CUTTING: Per-tenant IAM boundary · SCP guardrails · Env teardown automation · Cost tags per tenant
What Rahul owned

The useful proof is the decision surface, not only the result number.

These are the parts of the work that show production judgment: ownership, constraints, rollback, cost, and observability.

Owned scope

  • Platform foundation for repeatable environments, IaC, deployment paths, and operational ownership
  • Cost and reliability review for a SaaS product moving from pilot shape toward production scale
  • Developer workflow improvements so environments could be created and changed predictably

Evidence artifacts

IaC foundationEnvironment automation99.9% availability target40% AWS cut in sanitized story
Constraints

What would fail first?

Every project has constraints. The useful work is naming them early enough that rollback, cost, and ownership are designed before an incident.

ClickOps drift

Manual infrastructure changes made environments slow to create and hard to compare.

Small team

The platform had to reduce operational load instead of adding process overhead.

Growth pressure

Pilot decisions needed to become repeatable before more tenants and features arrived.

Decision table

Trade-offs accepted on purpose.

Option
Decision
Reason
DynamoDB vs PostgreSQL
DynamoDB chosen for single-digit ms latency and zero-ops scaling for unpredictable SaaS workloads
DynamoDB vs PostgreSQL: DynamoDB chosen for single-digit ms latency and zero-ops scaling for unpredictable SaaS workloads.
Lambda vs ECS
Lambda for API handlers (cost-efficient at variable traffic), ECS for long-running build jobs
Lambda vs ECS: Lambda for API handlers (cost-efficient at variable traffic), ECS for long-running build jobs.
Celery+SQS vs Step Functions
Celery chosen for flexibility in complex build orchestration workflows
Celery+SQS vs Step Functions: Celery chosen for flexibility in complex build orchestration workflows.
Risk table

Production risks and how they were controlled.

Risk
Mitigation
Owner
Environment drift broke releases
Moved environment contracts into reusable IaC and documented expected ownership.
Platform owner
Cost increased with every new tenant
Tracked service-level cost drivers and removed idle/non-production waste early.
Engineering + finance
Platform became another bottleneck
Optimized for paved paths and developer self-service rather than central approvals.
Platform + product teams
Implementation approach

Small steps, visible changes, fewer surprises.

  1. 01

    Mapped the existing manual infrastructure and documented 23 hand-provisioned resources across 3 AWS accounts with no IaC.

  2. 02

    Designed API-first architecture. Lambda handlers for all CRUD operations behind API Gateway with request validation and throttling.

  3. 03

    Built async build pipeline using Celery workers on ECS, SQS for job queuing, and S3 for artifact storage with lifecycle policies.

  4. 04

    Implemented DynamoDB single-table design with GSIs for multi-tenant access patterns, eliminating the need for a separate database per customer.

  5. 05

    Created Terraform modules for the full stack, enabling one-command environment provisioning for dev/staging/prod.

Result

Before and after.

Environment Setup
3 days (manual)
12 minutes (Terraform)
Monthly AWS Spend
baseline
~40% lower
API Latency (P95)
800ms
<100ms
Deployment Downtime
15-30 min/deploy
Zero (blue-green)

Rollback path

Rollback needed to be tied to deployment workflow, state changes, and environment promotion instead of manual memory.

Cost considerations

The primary savings path was right-sizing and removing manually-created resources that had no owner.

Observability notes

Environment health, deploy success, core API latency, and tenant-impact signals were the important baseline.

Related services

Forward Deployed AI EngineeringAWS Production Architecture ReviewGenAI / RAG Production Readiness

Have a similar production problem?

Send the current architecture, bill concern, deployment pain, or GenAI reliability issue. I will help you find the first real bottleneck.