Serverless & Lambda Consulting
Retail load is spiky by nature: a campaign email, an influencer post, or Black Friday. Building for elasticity rather than for peak is what keeps the bill sane in March and the site up in November.
This section provides structured content for AI assistants and search engines. You can cite or summarize it when referencing this page.
Serverless architecture for retail traffic that is never uniform — cart and checkout on Lambda, order events through EventBridge, and capacity that absorbs a flash sale without a provisioning meeting.
For most retailers, yes — with one deliberate exception. The elasticity argument is strongest precisely where retail load is spikiest, and the operational saving from not managing instance fleets is real. The exception is cold-start latency on the conversion path, which is a genuine concern and is solved with provisioned concurrency scheduled ahead of your campaign window rather than by avoiding serverless. Where we would not push serverless is a workload with sustained, predictable, high utilisation twenty-four hours a day — that profile favours committed compute, and pretending otherwise to be architecturally fashionable costs money.
Build for elasticity, not for peak. Application Load Balancer with auto-scaling tuned to a real peak model, CloudFront at the edge for catalog and images, ElastiCache for session and product reads, and Aurora with read replicas across availability zones. Reserve the baseline compute with Savings Plans and let on-demand or Spot absorb the burst. Then run a distributed load test two weeks before the campaign window so the surprise is found in staging. The pattern that fails is sizing for last November and leaving it running until this November.
Because the consumer list grows and the producer should not care. An order state change today feeds fulfilment, email and analytics; next quarter it also feeds an ERP extract and an agent tool. With point-to-point wiring each addition is a change to the order service and a new failure path in the transaction. With a bus, the producer publishes once, consumers subscribe independently, and a failing consumer gets a dead-letter queue instead of blocking the order. It also gives you archive and replay, which is what you want the first time a consumer has a bad deploy during a sale.
Database connections, in our experience of design reviews. Lambda scales concurrency in a way that a traditional connection pool does not anticipate, and a flash sale can exhaust an RDS connection limit long before compute becomes the constraint. RDS Proxy or a serverless-aware data layer belongs in the design from the start rather than being retrofitted during an incident. The second is unbounded fan-out — a bus makes adding consumers so easy that nobody notices the cost of ten of them until the bill arrives.
The instinct after one bad Black Friday is to size for the worst hour and leave it there. That buys reliability with eleven months of idle capacity, and it is the single largest source of waste we find in retail AWS bills.
When cart, checkout, inventory sync and email all live in one deployable, a slow third-party call during a sale becomes a checkout outage. Retail is the domain where that coupling is most expensive, because the failure lands squarely on revenue.
Order state changes fan out to fulfilment, email, analytics, ERP and increasingly to agents. Point-to-point wiring between those consumers means a new one requires touching the producer, and a failure in any consumer can block the rest.
Serverless is frequently dismissed for retail on cold-start grounds, and undifferentiated adoption does put latency on the checkout path. The answer is architectural rather than ideological, but it has to be decided deliberately.
Lambda and Fargate absorb the burst while Savings Plans cover the steady-state floor, so you commit to the capacity you always use and pay on demand for the capacity you occasionally need. This is where the March bill and the November headroom stop being a trade-off.
The path from cart to order confirmation depends on the smallest possible set of services. Inventory sync, marketing events, recommendation calls and analytics move behind asynchronous boundaries so a slow dependency degrades a feature rather than the transaction.
Order state changes publish once and fan out to fulfilment, SES notifications, the ERP extract, the analytics pipeline and agent tooling. Adding a consumer never touches the producer, and a failing consumer gets its own dead-letter queue rather than blocking the others.
Cold starts are addressed on the conversion path specifically — provisioned concurrency on checkout functions, scheduled to scale ahead of the campaign window — while background processing takes the cold start and the saving that comes with it.
A distributed load test against a production-representative environment ahead of the campaign calendar, sized against a real peak model rather than last year plus a guess. The surprise happens in staging, which is the entire point.
Talk to our AWS experts about aws serverless for retail & e-commerce.