E-commerce
storefronts that sell,even on sale day
Catalogs, carts, and checkouts that scale with the traffic instead of a capacity spreadsheet. Built so the busiest hour of the year is the one that works best.
Illustration: sample products are added to a shopping cart, the subtotal adds up, checkout completes as paid, and an order confirmation appears before the cart clears.
- faster peak handling after migration
- 5x
- uptime after cutover
- 99.9%
- infrastructure cost
- −40%
- branded booking sites on one engine
- 5
01 · The hard part
What breaks when the sale starts
Most stores work fine on a quiet Tuesday. The problems show up at 10x traffic, which is exactly when the revenue is.
Checkout fails at peak
Fixed hardware cannot absorb a sale. Carts time out right when the most people are trying to pay.
Catalog reads crowd out orders
Every product page hits the same database the orders write to, so browsing slows buying.
Every copy change needs a developer
Merchandisers wait on a deploy to change a banner, a price, or a landing page.
Carts that forget
A refresh or a second device empties the cart, and the shopper does not rebuild it.
02 · What I build
What I have built for stores
Three pieces of commerce work, from the infrastructure under the store to the cart on top of it.
Storefronts that scale with the sale
Containerized services behind a load balancer, with media at the edge and hot reads in a cache. Autoscaling follows the traffic, not a rack order.
Shipped in: E-commerce migration case study- ECS services behind an ALB
- CloudFront and S3 for media
- ElastiCache in front of the catalog
- RDS for catalog and orders
- Autoscaling on real load
- Staged cutover from on-premise
Headless storefronts on Next.js
Server-rendered product pages search engines can read, with content in a CMS editors use without opening a pull request.
Related work: Web development service- Next.js server rendering
- Contentful, Payload, or Prismic
- Editor previews before publish
- Structured data for products
- Image optimization at the edge
- Lighthouse budgets of 95+
Carts, checkout, and promotions
Persisted carts, Stripe checkout, and the promotion rules marketing actually asks for, on one payments engine.
Shipped in: Track Booking Platform- Carts that survive a reload
- Stripe checkout and stored cards
- Gift certificates and credits
- Promo codes
- Several branded storefronts, one engine
- Order notifications
03 · Stack
The tools behind the work
What the store runs on, from the page a shopper sees to the database the order lands in.
- Storefront
- Next.js
- React
- Redux
- Contentful
- Payload
- Prismic
- Payments
- Stripe
- Stripe Connect
- Infrastructure
- ECS
- ALB
- CloudFront
- S3
- ElastiCache
- RDS
- Delivery
- GitHub Actions
- CloudWatch
- Docker
- Terraform
04 · Ready for peak
Built for the busiest hour
The checks that make a sale day boring: security for the card path, and capacity for everyone else.
Card data stays with the processor
Checkout uses the processor's hosted fields and stored-card references. Card numbers never reach the store's database.
Media at the edge
Images and static HTML come from the CDN, so a spike does not hit origin for every product photo.
Autoscaling on real load
Services scale on request and CPU signals, with health checks that pull a bad task out of rotation.
Reads cached, writes protected
The catalog is served from cache; orders keep the database to themselves.
Secrets out of the repo
Payment keys and connection strings live in the cloud's secret store, rotated without a redeploy.
Preview deploys for every change
Every pull request gets its own preview, so a promo page is checked before it goes live.
PCI DSS validation is done by the merchant with their processor or assessor. The build is set up so that scope stays as small as possible.
Got a sale coming up?
Tell me what the store runs on and where it struggles at peak. I will come back with what I would change first and what it would cost to run.