AWS

The right AWS architecture for a marketing site, an internal tool and a multi-tenant SaaS are completely different. So I start with questions. What is the traffic shape — steady, spiky or batch? What latency do users need? What happens if this component is down for ten minutes? Who operates it, and what is the budget?

The answers usually point to a small number of services used well, rather than a diagram with every service on it.

Lambda behind API Gateway or an event source is excellent for spiky and event-driven work — file processing, webhooks, scheduled tasks, lightweight APIs — because you pay per execution and don't patch servers.

The trade-offs are real: execution time and payload limits, cold starts that matter for some latency-sensitive endpoints, harder local debugging, and per-request costs that can exceed a small always-on server at sustained high volume. Long-running or stateful work often belongs in containers or queue-driven workers instead.

S3 is the default home for files: user uploads, generated exports, static assets. Buckets stay private; public delivery is the exception and usually goes through CloudFront.

For uploads, the backend issues short-lived presigned URLs so files go straight from the browser to S3 without passing through the application server. Lifecycle rules move or expire old objects, and keys include the tenant so access rules and clean-up stay simple.

DynamoDB rewards designing from access patterns: list the queries the application will run, then choose partition and sort keys so each one is a key lookup or a range query. Partition keys need enough spread to avoid hot partitions.

It's a strong fit for high-scale key-value access, session or event data and predictable query shapes. It's a poor fit when requirements are still moving, when you need ad-hoc reporting, or when the data is deeply relational — which describes many early-stage SaaS products.

For most business applications and SaaS products a relational database is the better default: transactions, joins, constraints, flexible queries and reporting. A managed relational database removes the work of backups, patching and failover. I'd rather start relational and move specific hot paths to specialised stores than force a relational domain into a key-value model.

Decoupling slow work from user requests is one of the highest-value architecture decisions. A queue between the API and its workers absorbs spikes, enables retries and lets each side scale independently. Messages must be safe to process more than once, and failures need a dead-letter destination someone actually looks at.

Every role gets only the permissions its workload needs, scoped to specific resources — not wildcards because they were quicker to write. Workloads use IAM roles and temporary credentials, never long-lived access keys in code. Human access to production is limited and auditable.

Configuration varies by environment; secrets never belong in source control. They live in a managed secret store or encrypted parameters, are injected at runtime, are rotated where possible, and never appear in logs.

Production visibility means structured application logs with request and tenant context, alarms on error rates and queue backlogs, and metrics that reflect the product — failed jobs, processing latency, failed payments — not just CPU. Logs have a cost too, so retention and verbosity are decisions, not defaults.

Cost follows architecture. I estimate it from expected usage before choosing a design, tag resources so spend can be attributed, set budgets and alerts, and remove infrastructure that exists only because someone might need it one day.

A pattern I favour for uploads that need processing — parsing, conversion, extraction: the client asks the API for a presigned URL, uploads directly to S3, the upload triggers asynchronous processing, and the results are stored and surfaced back to the user.

The API never handles the file bytes, processing can retry on its own, and the user isn't waiting on a long request.

For SaaS, the infrastructure questions follow the product's: an API layer, a relational database for core data, S3 for files with tenant-prefixed keys, queues and workers for asynchronous jobs, CloudFront for static assets, and separate environments with CI/CD.

Multi-tenant workloads add noisy-neighbour concerns — one customer's large import shouldn't slow everyone else down — so heavy work goes through queues with per-tenant limits.