Shopify handles the storefront, the checkout, and the cart. That's most of the work. But about half the merchants we talk to want something Shopify won't do natively—a product configurator with hundreds of variants, a loyalty engine with custom tier rules, a B2B portal with negotiated pricing, an ERP sync that runs every five minutes.
All of that lives outside Shopify. The question is where. We almost always land on the same AWS shape.
The shape, in one paragraph
API Gateway in front of Lambda for synchronous requests from the storefront. EventBridge as the bus between Shopify webhooks, Lambda consumers, and downstream services. DynamoDB for hot data, RDS Postgres for relational depth, S3 for everything else. CloudFront where speed matters. The whole thing fits on a napkin and runs for a few hundred dollars a month at small scale.
Why serverless wins here
Shopify traffic is spiky by nature. A morning campaign sends 50x normal load for thirty minutes, then it's quiet for hours. Lambda + API Gateway scale to that in milliseconds and bill in milliseconds. You don't run idle clusters.
Cold starts used to be the objection. With provisioned concurrency on the two or three Lambdas that sit on critical paths, p99 stays under 200ms. The rest can warm on demand without the customer noticing.
Webhooks: where most projects break
The pattern we see fail most often is processing Shopify webhooks synchronously inside a Lambda hooked to API Gateway. Shopify retries aggressively if you don't 200 within five seconds, and you'll process the same order three times the first day a downstream system slows down.
The fix: API Gateway receives the webhook, validates the HMAC, drops the payload on EventBridge, returns 200 immediately. Downstream Lambdas process the event at their own pace. Idempotency keyed on order ID. Failed events go to a DLQ and get retried with backoff.
The minimum webhook plumbing
- HMAC verification using the shared secret, in the receiver Lambda.
- EventBridge bus, one per environment.
- DLQ with a CloudWatch alarm so failures don't pile up silently.
- An idempotency table in DynamoDB to deduplicate retries.
Data: hot vs. warm vs. cold
DynamoDB for anything queried by ID at storefront latency—cart state, loyalty balances, configurator selections. Postgres for anything joined or reported on—B2B price lists, order history, customer hierarchies. S3 for artifacts and historical exports.
Resist the urge to put everything in Postgres because it's familiar. Storefront latency budgets are 100ms, not 500ms, and a single RDS round-trip eats most of that.
The Shopify side, briefly
Storefront calls hit your backend through App Proxy or directly to a custom domain. Authenticated session is verified via the signed proxy request. For embedded admin tooling, OAuth + session tokens. None of this is glamorous, all of it is in Shopify's docs, almost everyone gets it slightly wrong the first time.
What it actually costs
At the scale we typically see—a few thousand orders a day, a million webhook events a month, a B2B portal with a few hundred active users—this stack runs ₹15K–₹40K/month on AWS. The Lambda bill is rounding error. The cost lives in NAT gateway data, CloudWatch logs, and an RDS instance that's larger than it needs to be.
Optimize those in that order. The architecture is the easy part.