Physics of Systems
The systems that run our world are hiding in plain sight. You interact with them dozens of times a day and most of the time, you might wonder how any of it actually works.
Physics of Systems is your invitation to look under the hood. Each article takes one complex system, strips it down to its parts, and rebuilds it piece by piece, until it just makes sense.
Welcome to part 2, what Happens When You Switch Countries on Amazon.
I want you to do something for me!
Open the Amazon app on your phone and find the little flag in the corner. Switch your home country to some other country. Move from India to the UK and observe the changes. Then, flip it to the USA.
Go ahead. I'll wait.
Did you notice what just happened?
The delivery promise changed. The payment options changed. The featured services changed.
In India, You see Amazon Now (10-minute delivery), Amazon Pay , Fresh and Baazar.
In the UK, those top-level apps disappear, Deals under £ 15 and HBO & Prime benefit shows up.
In the US, We get to see Alexa woven into the core shopping flow.
Same app. Same phone in your hand. Three completely different experiences.
Most people see that and think: oh, it just changes the language and currency. Well that's not it.
What you just witnessed is one of the most sophisticated distributed systems ever built. In two seconds, Amazon swaps services, UI, and the entire backend stack based on your region.
I mean, wow. If you're not enthusiastic about this, you should be, because it's about to get real interesting.
How does Amazon switch countries
if country == "IN": show Indian stuff
if country == "US": show American stuff
Cute but not even close.
Country is not a setting. It's a routing key.
It's a key that every single layer of Amazon's infrastructure reads independently and acts on.
The CDN responds to it.
The database partitions on it.
Payments interpret it.
Compliance enforces through it.
Features reshape around it.
When you tapped that flag, you didn't change a preference. You moved. From one world to another new world.
The Architecture
I pushed myself to really understand the region specific features and services flow. Then I tried to capture it, what you see below is my attempt to trace the flow.
Layer 1: Client Layer
You tap the flag. You select UK.
One thing happens before anything else: your country preference is written to a signed session cookie. That cookie travels with every single request from this moment forward. Every service downstream will read it, and every service will make its own decision based on it.
This is the core design choice.
Amazon didn't build a central service for country switching. Instead, they decentralized it: every layer reads the same key and decides for itself. Ownership is distributed across the entire stack.
Layer 2: Edge Layer
Before your request even reaches a server, it passes through AWS Route 53.
AWS Route 53
This is Amazon’s global DNS (Domain Name System). Yes, it is kind of like "Internet's Address Book" but with a brain: it checks your location and locale to resolve Amazon.com to the specific IP address of the closest healthy regional stack.
India (Amazon.In): Mumbai (AP-SOUTH-1)
UK (Amazon.co.uk): London/Ireland (EU-WEST-2 / EU-WEST-1)
US (Amazon.com): Virginia/Oregon (US-EAST-1 / US-WEST-2)
You don't choose latency. It gets chosen for you.
Amazon CloudFront
This is a Content Delivery Network (CDN) that caches the "skin" of the app (HTML, CSS, JS, and product images) at hundreds of edge locations worldwide.
It sits at those edge locations and it's already pre-loaded with the UK storefront's static assets for the UK experience.
Sitting on a server physically close to you. Ready to serve in milliseconds. The switch feels instant because nothing is traveling far. You're pulling from something nearby.
Then, Lambda@Edge
A tiny function running directly on CloudFront's server, intercepts your request before it goes anywhere else. It reads your country preference from your session cookie. And it stamps one header onto your request:
X-Country-Code: gb
That one header. That's the routing key now in flight.
From this moment forward, every service your request touches will read that header and know exactly what to do.
Layer 3: API Layer
Your request, now carrying its locale header, hits
Amazon API Gateway
This is the traffic controller,
And it routes your request to the correct regional service instance.
From there it reaches the,
Backend for Frontend (BFF) running on ECS
Your app makes one request, but it needs many answers. The BFF reads your locale key and fans out parallel requests to the catalog, pricing, and payment services. It gathers these 5–10 parallel responses, shapes them, and returns one unified payload to your phone. To you, it's one page load. Underneath, multiple systems move at the same time, happening all in milliseconds.
Amazon ECS (Elastic Container Service) is the orchestration layer that manages the lifecycle of the BFF’s containers, allowing it to instantly scale to handle regional traffic surges like a Big Billion day sale or Black Friday.
Layer 4: Service - Where the Country Experience Is Built
AWS AppConfig
This is where features get decided.One app. One codebase. But not one experience. AppConfig holds a simple mapping of "country → feature set" that can be updated in real time, without a single code deployment.
Inside the India experience, there's a feature called Amazon-Now , when you're in India and your pin code falls inside a serviceable zone, the Amazon-Now App's widget renders. and now you can order groceries and expect delivery under 10 minutes.
The app's code for this feature exists on your phone right now, even if you're in the UK. But there's a gate. A flag. And in the UK, that flag is off.
In the US, there's a flag for Alexa+, Amazon's generative AI assistant, with the ability to book home repairs, order groceries, manage your smart home through conversation. That flag is on in the US. In India? Off.
Pause on what that means.
A new delivery zone in Pune doesn't require a release.No update.No rollout cycle. They flip a flag in AppConfig and the feature lights up. If something goes wrong, they flip it back. In seconds.
AWS Systems Manager Parameter Store
Handles the simpler, stable values, Prime pricing per country, supported card networks, whether same-day delivery is available in a region. Less dynamic, but equally essential.
Services
This is the richest layer. I think they should have attest 5 of these services. These five services gets fired in parallel. Each one reads the same locale key. Each one returns something completely different depending on where you are.
1. Catalog Service, Your Products Are Not My Products
When you search "tea" in India vs the UK, you're not searching the same catalog. Amazon's catalog is sharded by geography.
The India catalog shows regional grocery brands, local electronics and it lives in a completely separate partition from the UK catalog. The Catalog Service running on ECS routes your query to the correct shard, and only that shard.
2. Pricing Service
GBP with VAT-inclusive display for the UK. INR with GST-inclusive for India. Pre-tax in USD for the US. Same service. Different output. Driven entirely by the locale key.
3. Payment Service
Switch to India and you see UPI, Net Banking, Pay on Delivery, EMI on credit cards.
Switch to the US and you see Amazon Pay, major credit card networks, Alexa-linked grocery payments.
Switch to the UK and you see different card networks, no UPI, different instalment options.
None of this is hardcoded in the app. There's a payment method configuration service that reads your country key and returns the correct list dynamically. The checkout screen is a renderer, it has no idea what it will show until the config service responds.
4. Serviceability Service
This one is underappreciated. For every product, and for every delivery feature like Amazon Now, a serviceability check runs: is this available in your pin code? What's the ETA?
In India, the Serviceability Service checks your pin code against Amazon Now's dark store zones. In the UK, it checks your postcode against standard fulfilment coverage. If Amazon Now isn't available in your zone, the widget doesn't render, not only because of a feature flag, but because the serviceability check returned false. Two gates. Both must be open for the feature to appear.
Layer 4b: Async Layer
Not everything happens in real time. Price updates, inventory changes, payment partnership additions, these flow through the async layer.
Amazon EventBridge
Handles the event-driven updates. Something happens → an event fires.
The Scenario: A seller in UK marks an item as "Out of Stock"
The Action: An event fires. Instantly, the "Buy Now" button on the product page disables and the search index hides the item.
The Result: The frontend updates in real-time globally without a single line of code being redeployed.
SQS/SNS
These services handle Asynchronous Messaging, allowing different parts of the system to talk to each other without waiting for a response.
SNS (Simple Notification Service): A Broadcaster that sends a single message to multiple subscribers at once (one-to-many).
SQS (Simple Queue Service): A Waiting Room that holds messages in a line until a service is ready to process them (one-to-one).
Imagine a "Lightning Deal" starting in Mumbai.
SNS blasts the price update to three different places simultaneously: the Product Page, the Mobile Push Notification service, and the Marketing Email service.
SQS catches the massive flood of incoming orders. Instead of the database crashing under the weight of 100,000 clicks per second, the orders sit safely in the queue. The "Order Processor" service pulls them out one by one at a speed it can handle.
Layer 5: Data Layer
Look at the data layer in the diagram. Notice something: it shows IN, US, UK partitions for both DynamoDB and Aurora. That's intentional.
DynamoDB Global Tables
Stores the catalog and session data, partitioned by country. Your India session data lives in Mumbai. Your UK session data lives in EU-WEST. They don't share a table. They don't share a cluster.
Aurora Global Database
Handles relational queries, order history, account details, transactional records. Each region has read replicas serving local queries. Writes go to a primary, replicated asynchronously.
ElastiCache (Redis)
Redis acts as the system's High-Speed Memory, serving data in microseconds so the database doesn't have to do the same work twice.
The Big Billion Day (India) Scenario:
During the first minute of the sale, 10 million users request the "Mobile Deals" page.
Without Redis: The system "fans out," hitting the database 10 million times to calculate discounts and inventory. The database crashes.
With Redis: The system calculates the deals once, stores the result in the India ap-south-1 cache, and serves the next 9,999,999 requests directly from RAM.
Lightning-fast load times during peak traffic and a backend that doesn't melt under the pressure.
Fault Isolation: If Amazon India's catalog service has an outage at 2am IST, it doesn't take down Amazon UK. The UK stack reads from its own data layer. The fault has a border.
Sharding data by geography isn't just about performance. It's about building systems where failure doesn't travel.
Layer 6: Observability Layer
This layer sits on the right side of the diagram, watching everything.
AWS CloudWatch
Gives each region its own dashboards and alarms. Engineers watching India metrics see India error rates and latency, isolated from UK or US. When India's Diwali traffic spikes, it shows up on India's dashboard. It doesn't pollute UK's.
AWS X-Ray
Trace Map every request. If a page load feels sluggish, X-Ray pinpoints the exact bottleneck in the chain.
It visualizes the flow: AppConfig → Catalog Service → Serviceability Check. You don't guess why the India site is slow; you see that the "Catalog Service" took 400ms to respond.
IAM + KMS
This is where Legal Compliance is enforced by code.
IAM (Identity & Access Management): Service Control Policies (SCPs) act as a digital fence, physically preventing data from being moved out of a specific region.
KMS (Key Management Service): Generates region-specific encryption keys.
Compliance
India has the Digital Personal Data Protection Act. The UK and EU have GDPR. The US has CCPA in California and a patchwork of state laws. Each one mandates different data handling, different consent flows, different residency requirements.
When you're on Amazon India, your data stays in AP-SOUTH-1 — Mumbai. When you're on Amazon UK, your data stays in EU-WEST. This isn't Amazon being generous with infrastructure. It's legally required. Data residency is a hard constraint baked into the architecture.
Data encrypted in EU-WEST literally cannot be decrypted by a service running in US-EAST.
Amazon Macie detects PII that shouldn't cross regional boundaries.
Tax logic is a rules engine, a configuration-driven service that maps country to tax rules. India renders GST-inclusive. UK renders VAT-inclusive. US renders pre-tax with state-level tax applied at checkout. Same service. Different rules loaded from config.
Compliance isn't a feature you add at the end. In this architecture, it's a routing constraint built into every layer from day one.
Moving beyond the plumbing of services, the framework Internationalization and Localization
There are two things happening when you switch languages that most people conflate.
Internationalization (i18n) - is the infrastructure. It's the system that makes it possible to render different languages, scripts, currencies, and formats. It's the framework.
Localization (l10n ) - the content itself. The translations, symbols, formats for a specific locale.
When you switch to the UK, Strings flip from
These locale bundles, JSON files are stored in Amazon S3 and served through CloudFront. Because they're static files, they're cached at the edge. The swap is near-instant.
Designing for Failure
Here's something that never shows up in system design diagrams, but drives more architectural decisions than anything else.
When Things Break - And They Will
This architecture fails. Services go down. Latency spikes.
Circuit breakers
Prevent cascading failures. Imagine you tap Amazon Now at 11pm. The serviceability service - the one checking if your pin code is covered - starts lagging.
Without a circuit breaker, that lag spreads and your screen freezes.
With one, the circuit opens instantly. Amazon stops calling that service. You see standard delivery options instead of the 10-minute widget. No spinner. No crash. Just a slightly different screen.
Graceful degradation
Means every non-critical feature has a fallback. Can't reach the recommendations engine? Show bestsellers. Can't reach real-time inventory? Show the product without stock count. The app keeps working.
Geographic sharding is itself a resilience strategy. India's Diwali traffic surge doesn't affect UK response times. They're separate stacks, independently scaled with AWS Auto Scaling, independently monitored with AWS CloudWatch dashboards.
When something goes wrong in one country. AWS Resilience Hub lets teams define acceptable RTO and RPO per regional workload and test against them.
The Full Journey, Start to Finish
You tap "Switch to UK".
Client layer: Country preference written to signed session cookie. Routing key is born.
Edge layer: Route 53 routes you to EU-WEST. CloudFront serves cached UK static assets from a nearby server. Lambda@Edge stamps X-Country-Code: gb on your request.
API layer: API Gateway authenticates you, applies UK rate limits, routes to UK BFF on ECS.
Service layer: BFF fans out to five services in parallel - AppConfig returns UK feature flags, Catalog Service returns UK-specific products from DynamoDB EU shard, Pricing Service returns GBP with VAT-inclusive display, Payment Service returns UK card networks and options, Serviceability Service checks your postcode for delivery availability.
Async layer: EventBridge propagates any config changes. SQS/SNS handles inventory and pricing updates in the background.
Data layer: ElastiCache caches the composed response. DynamoDB and Aurora serve from EU-WEST partitions only.
Observability layer: CloudWatch logs the request to UK dashboards. X-Ray traces the full call chain. IAM + KMS ensures your data never leaves EU-WEST.
Your phone renders the UK experience.
The Shift in Me
I’ve spent enough time architecting systems to realize that the hardest problems aren't the technical ones - it's your engineering philosophy.
If you’d asked me how to "add India support" five years ago, I would have reached for an if-else block. I’d have suggested adding country-specific code and conditional logic. But that's how you build a monolithic app that eventually collapses under the weight of its own complexity.
Today, this architecture teaches a different lesson: Don't add conditions to your code; build systems that scales.
Decentralize the Decision: Instead of one service "owning" the country switch, make every microservice read the routing key and decide for itself.
Config over Code: Push variation into configuration bundles (like those JSON files in S3) rather than hardcoded logic.
Compliance as a Constraint: Treat regulations like GDPR or India’s DPDP Act not as "features" to be added later, but as architectural boundaries - like using KMS to ensure data literally cannot leave its home region.
The goal isn't just to build an app that works in 20 countries. It’s to build an infrastructure where adding the 21st country is a config change, not a six-month project.
That is the difference between a codebase that grows and a system that actually scales.
A note: This is an architectural interpretation, not Amazon's internal blueprint. The patterns and services are real , the exact implementation is ours to reason about. That's the point.
Every system you just read about was built by someone who stared at a hard problem and found a way through.
Once you understand how a system is built, you start seeing its fingerprints everywhere. In the apps you use. In the products you build. In the decisions you make.
That's the thing about systems, they reward the curious. There are a lot more layers to uncover.
Join the conversation! Your thoughts help the community grow.