Serverless Posts

Every e-commerce team starts with a synchronous checkout. The API receives a cart, charges the card, decrements inventory, and returns a confirmation. It works until it doesn't. Payment processors time out. Warehouses operate on batch cycles. Inventory reservations race against each other across regions. I have rebuilt checkout and fulfillment pipelines three times across different organizations, and every rebuild ended at the same place: an asynchronous state machine with compensating transactions. AWS Step Functions is the right tool for this job, and this article covers the specific patterns, cost math, and operational lessons from running cart-to-delivery workflows in production.

Every platform that accepts user-uploaded video faces the same operational reality: a single piece of unmoderated content can produce legal liability, advertiser flight, and reputational damage that takes months to repair. I have built content moderation systems for platforms processing thousands of hours of video per day, and the architectural pattern I keep returning to is a Step Functions orchestration layer coordinating AWS managed AI services. Rekognition scans frames for nudity, violence, hate symbols, and other policy violations; it also identifies celebrities and labels objects and scenes. Transcribe pulls the audio track into a timestamped transcript. Step Functions ties these asynchronous, variable-duration jobs into a single deterministic pipeline that writes a structured metadata package back to S3 alongside the original video. This article is the architecture reference for that pipeline: the service integrations, the ASL definitions, the failure modes, the cost model, and the operational lessons that only surface under production load.

DynamoDB sits at the center of more AWS architectures than any other database service. I've used it for everything from mobile backends handling millions of daily active users to event-sourced systems processing tens of thousands of writes per second. Most teams treat it as a simple key-value store, plug it in, and move on. That works until they hit a hot partition at 3 AM, discover their GSI is throttling independently of the base table, or realize their on-demand table costs three times what provisioned capacity would have. After years of running DynamoDB at scale, I've accumulated enough operational scars to fill this reference. Patterns, trade-offs, cost traps, and the internal mechanics that explain why DynamoDB behaves the way it does.

Most teams bolt messaging onto their architecture after the first production outage caused by synchronous service-to-service calls. A payment service calls an inventory service directly, the inventory service is slow, the payment service times out, the customer gets charged twice. Suddenly everyone agrees the system needs a queue. I have spent years designing event-driven systems on AWS: order processing pipelines handling millions of transactions per day, IoT telemetry ingestion at hundreds of thousands of events per second, multi-region fan-out architectures coordinating dozens of microservices. AWS offers at least six distinct messaging and eventing services. Each solves a different problem. Choosing wrong means either overengineering a simple notification flow or discovering at 3 AM that your architecture cannot handle the throughput your business requires. This article is not a getting-started guide. It is an architecture reference for engineers who need to pick the right service, configure it correctly, and avoid the failure modes that surface only under production load.

Having spent years packaging Lambda functions as zip archives, I hit the wall that every team eventually hits: the 250 MB deployment package limit. The first time it happened was an ML inference function with a PyTorch model and its dependency tree. We burned weeks trying to strip binaries, use Lambda Layers creatively, and shave megabytes from scipy. When AWS launched container image support for Lambda in December 2020, it raised the size ceiling to 10 GB and fundamentally changed how I think about Lambda packaging, base image standardization, CI/CD pipelines, and the boundary between serverless and container workloads. Container images let you use the same Dockerfile, the same build toolchain, and the same base image across Lambda, ECS, and Fargate, which eliminates an entire category of "works in my container but not in Lambda" problems.

Five ways to expose a Lambda function over HTTP. At least. AWS keeps adding more. Most teams pick API Gateway on day one and never revisit that decision. Fine. API Gateway handles a lot.

Most teams ignore Step Functions until they find themselves writing ad-hoc state management code inside Lambda functions, chaining queues together with brittle retry logic, or building homegrown saga coordinators that nobody wants to maintain. The service is a fully managed state machine engine that coordinates distributed components (Lambda functions, ECS tasks, DynamoDB operations, SQS messages, human approvals, and over two hundred other AWS service actions) through a declarative JSON-based workflow definition. I have spent years building production orchestration on Step Functions: ETL pipelines processing billions of records, saga-based transaction systems spanning dozens of microservices, real-time data enrichment at tens of thousands of events per second. This article captures what I have learned about the internals, the trade-offs, the failure modes, and the patterns that survive contact with production traffic.

Amazon API Gateway sits in front of most serverless and microservice architectures on AWS. Three distinct API types, a control plane versus data plane split, a layered throttling hierarchy, a caching layer, a rich integration model. Most teams deploying API Gateway never dig into these mechanics. I have spent years building and operating API Gateway-backed systems handling everything from low-traffic internal tools to production APIs processing tens of thousands of requests per second, and I learned most of the hard lessons the hard way.