Every system starts with the business problem. From there the work moves forward — actors, capabilities, access patterns, architecture — and only then do the services get chosen.
That approach came from repetition, not theory. Across four production-oriented serverless systems, the pattern that mattered most was the why behind each decision — what business requirement it satisfied and what trade-off it introduced.
A dashboard showing total clicks is straightforward to build. The decision to let a redirect succeed even when its analytics update fails — because a user should always get where they're going regardless of a tracking hiccup — is where the real engineering thinking lives.
Currently completing B.Tech in Computer Science Engineering at ITER, SOA University. Selected as Team Lead during my cloud engineering internship at F13 Technologies for how I broke down and owned architecture decisions across a team.
Business Problem
↓
Business Requirements
↓
Actors & Capabilities
↓
Architecture
↓
Engineering Decisions & Trade-offs
↓
AWS Services Selection
↓
Infrastructure as Code (Terraform)
↓
Implementation
↓
Production Improvements
AWS shows up two-thirds of the way down that list — deliberately. It's the last decision, not the first.
| Principle | What it means in practice |
|---|---|
| Business First | Architecture serves a requirement — it exists to solve something real |
| Design Before Implementation | Access patterns and data models get worked out before a single table is created |
| Serverless by Default | Compute should scale with demand, not sit idle waiting for it |
| Least Privilege | Every Lambda gets its own role, scoped to exactly what it touches |
| Cost Awareness | Every architectural choice has a dollar figure — I track it, not guess it |
| Infrastructure as Code | Every resource is defined, versioned, and reproducible from a single apply |
| Maintainability | Each component owns exactly one responsibility |
Flagship project
The center of this system is the registration, not the event. Every downstream action — ticket generation, delivery, attendance tracking — exists because a registration succeeded, and that insight shaped the entire architecture.
Registration is decoupled from ticket generation using EventBridge: the Registration Lambda writes to DynamoDB and returns success immediately, while a separate Lambda handles QR generation, S3 storage, and SES delivery asynchronously. Three DynamoDB tables are modeled around access patterns with Global Secondary Indexes. Auth runs on Cognito JWTs with role-based authorization, least-privilege IAM, and ticket files stay private in S3 — accessible only through short-lived pre-signed URLs.
Cognito EventBridge DynamoDB Lambda API Gateway CloudFront S3 SES Terraform
Split into three independently deployable capabilities — link creation, redirection, and administration — instead of one large function. The redirect path is intentionally prioritized over the analytics path: a click-count update can fail gracefully while the user is still redirected. The core user experience always takes priority over instrumentation.
DynamoDB uses the short code as a hash key for single-digit-millisecond lookups. Frontend hosted on S3 static website. Full infrastructure deployed through CloudFormation.
Lambda API Gateway DynamoDB S3 CloudFormation IAM CloudWatch
A four-stage event-driven pipeline — upload, Textract extraction, skill parsing, job matching — where each stage triggers the next through S3 events and DynamoDB Streams rather than one service handling everything sequentially. Textract handles document intelligence so the parsing logic works on structured extracted text, keeping each stage focused on a single responsibility. Each stage can evolve or scale independently.
Textract Lambda S3 DynamoDB Streams API Gateway IAM Terraform
The core decision: keep Lambda out of the file transfer path entirely. The frontend uploads directly to S3 using a pre-signed URL that a lightweight Lambda authorizes — Lambda grants permission, S3 handles the transfer. An S3 ObjectCreated event triggers image processing into three resolutions, stored in a separate output bucket for cleaner IAM boundaries. All 30 resources provisioned through Terraform.
S3 Lambda API Gateway Terraform IAM Pillow
Cloud AWS — Lambda · API Gateway · EventBridge · DynamoDB · S3 · Cognito · SES · CloudWatch · IAM · VPC · Route 53 · Textract · EC2 · ECS · EKS
Infrastructure as Code Terraform · CloudFormation · AWS CDK
Containers Docker · Kubernetes · Helm · ArgoCD
CI/CD GitHub Actions · Jenkins
Monitoring CloudWatch · Prometheus · Grafana · ELK Stack
Programming Python · JavaScript · Bash · Java · C++
Being upfront rather than inflating it. Right now I'm deepening:
- Python — moving from scripting Lambda handlers to writing production-grade, tested code
- Kubernetes — patterns beyond deployments and services: HPA tuning, ingress design, real workload orchestration
- Linux fundamentals — the layer underneath the managed services I've been building on
- Observability — structured logging, tracing, and alerting, not just dashboards after the fact
"Good cloud architecture is about moving data as little as possible while moving permissions intelligently."