Amazon is the world's largest e-commerce platform, serving over 300 million active customers across 200+ countries and territories. It hosts 2 billion plus products in its catalog from 2 million plus third-party sellers alongside its own retail inventory, ships 1.5 million plus packages daily through a network of 200+ fulfillment centers, and generates over 600 billion dollars in annual revenue. During peak events like Prime Day, the platform processes 12 billion dollars plus in sales within a 48-hour window, handling 10 million plus requests per second at the application layer. This scale introduces extraordinary engineering challenges: maintaining sub-100ms page loads for product detail pages, ensuring zero overselling during flash sales, powering a recommendation engine that drives 35% of all revenue, and orchestrating a global logistics network that delivers packages within hours rather than days.
This guide provides a comprehensive, senior-level deep-dive into designing every major subsystem of Amazon's e-commerce platform from first principles. We dissect the product catalog and search infrastructure, the shopping cart with cross-device persistence, the order management pipeline with inventory reservation, the payment processing system with fraud detection, the recommendation engine with collaborative filtering, the fulfillment and logistics system with warehouse automation, and the strategies that keep the platform stable during Prime Day traffic spikes. Each section includes production-grade C# code samples, Mermaid architecture diagrams, detailed comparison tables, and interview questions commonly asked at FAANG companies. Whether you are preparing for a system design interview at Amazon, Google, or Meta, or building an e-commerce platform at scale, this guide gives you the architectural vocabulary and implementation depth needed to operate at the senior staff engineer level.
1. Requirements, Scale, and Estimations
Before writing a single line of architecture, we must anchor every design decision in concrete numbers. Amazon's public disclosures, SEC filings, and engineering blog posts give us a remarkably detailed picture of the system's operating envelope. The following table captures the key scale parameters that drive every downstream design choice, from database sharding strategies to cache eviction policies to the number of microservices in the deployment topology.
| Metric | Value | Design Implication |
|---|---|---|
| Active customers | 300M+ | User service must handle 300M+ profile records; auth tokens in Redis |
| Products in catalog | 2B+ | Document store with partitioning by product ID; Elasticsearch index sharding |
| Third-party sellers | 2M+ | Seller isolation, per-seller inventory, marketplace billing |
| Packages shipped daily | 1.5M+ | Fulfillment pipeline must sustain 17+ packages/second sustained |
| Fulfillment centers | 200+ | Multi-region inventory, FC-aware routing, cross-FC transfer |
| Prime members | 200M+ | Priority fulfillment SLAs, dedicated delivery fleet |
| Peak QPS (Prime Day) | 10M+ | Cell-based isolation, pre-scaling, graceful degradation |
| Product categories | 50+ | Category-specific attributes, faceted search per category |
| Average order value | $35 | Payment processing optimization, micro-transaction handling |
| Return rate | 15-20% | Reverse logistics pipeline, refund processing, restocking |
| Review submissions daily | ~5M | Content moderation pipeline, spam detection, ML filtering |
| Search queries per second | ~100K | Elasticsearch cluster sizing, result caching, query routing |
Functional Requirements
- Product browsing: Users can search, filter, sort, and browse 2 billion plus products across 50+ categories with faceted navigation including price, brand, rating, size, color, and Prime eligibility.
- Product detail pages: Display title, description, multiple images, pricing, availability, seller information, reviews, Q&A, and related products with sub-100ms latency.
- Shopping cart: Persist cart across sessions and devices. Support guest carts that merge with user carts on login. Real-time inventory status on each cart item.
- Checkout and payment: Support credit/debit cards, Amazon Pay, gift cards, EMI, and one-click checkout. Validate address, apply coupons, calculate tax and shipping.
- Order tracking: Real-time order status from placement through fulfillment, shipping, and delivery with push notifications.
- Returns and refunds: Initiate return requests, generate return labels, process refunds or replacements through reverse logistics.
- Recommendations: Personalized product recommendations, frequently bought together, customers who viewed also viewed, and sponsored product placements.
- Seller marketplace: Seller onboarding, product listing management, inventory uploads, order fulfillment (FBM) or Amazon fulfillment (FBA), and seller analytics.
Non-Functional Requirements
- Availability: 99.99% uptime (52 minutes downtime per year). The checkout path must be available even during partial system failures.
- Latency: Product page load under 100ms (p99). Search results under 200ms. Cart operations under 50ms. Checkout confirmation under 500ms.
- Consistency: Strong consistency for inventory (no overselling) and payment (no double charges). Eventual consistency acceptable for reviews, recommendations, and search indexing.
- Durability: Zero data loss for orders and payments. Event sourcing with Kafka ensures every state transition is replayable.
- Scalability: Linear horizontal scaling. The system must handle 10x normal traffic during Prime Day without manual intervention.
- Security: PCI DSS compliance for payment data. GDPR compliance for customer data. Encryption at rest and in transit. Fraud detection on every transaction.
C#
// Back-of-the-envelope calculations
public class ScaleEstimations
{
// Daily active users: 100M (out of 300M registered)
// Each user views ~10 product pages per session
// Product page QPS: 100M * 10 / 86400 ~ 11,500 QPS
// Peak (3x): ~35,000 QPS for product pages alone
// Search QPS: ~100K queries/second sustained
// Cart operations: ~50K writes/second (add/update)
// Order placement: ~5K orders/second sustained, 50K peak
// Inventory updates: ~10K writes/second (reserve + commit)
// Storage calculations:
// 2B products * 2KB average metadata = 4TB (DynamoDB)
// 2B products * 10 images * 500KB = 10TB (S3)
// 300M users * 5KB profile = 1.5TB (DynamoDB)
// 10B orders * 5KB = 50TB (partitioned by time)
// Elasticsearch index: ~2TB (sharded across 100+ nodes)
// Bandwidth:
// Product pages: 35K QPS * 50KB average = 1.75 GB/s
// Images (CDN): ~10 GB/s served from edge locations
// Search: 100K QPS * 2KB query + 50KB results = 5.2 GB/s
}Capacity Planning for Peak Events
Capacity planning at Amazon is a continuous process driven by historical data analysis, seasonal forecasting, and event-driven projections. The team analyzes traffic patterns from the previous Prime Day, Black Friday, and Cyber Monday to establish baselines. Each microservice has a capacity model that translates QPS targets into infrastructure requirements: DynamoDB read/write capacity units, Elasticsearch shard counts, Redis cluster node counts, and ECS task scaling policies. The model accounts for the hottest partition problem: during Prime Day, a single popular deal product might receive 100x normal traffic, requiring DynamoDB adaptive capacity and Elasticsearch hot node allocation to handle the skew without latency degradation.
Infrastructure provisioning follows a three-phase approach: steady-state capacity handles normal daily traffic with 30% headroom, burst capacity handles 3x normal traffic during sales events, and emergency capacity handles 10x normal traffic during Prime Day with pre-warmed instances standing by. The pre-scaling process begins two weeks before Prime Day, gradually increasing cluster sizes and warming caches. Load testing with production-identical traffic patterns validates that each service can handle its projected peak QPS within latency SLOs. Any service that fails load testing is flagged for remediation, and the team must provide a written plan for fixing the bottleneck before the event.
Data Flow Architecture
Understanding how data flows through Amazon's architecture is critical for making informed design decisions. When a customer searches for a product, the request flows from the mobile app through CloudFront CDN (which serves cached search pages for anonymous users), through the WAF (which blocks bot traffic and applies rate limits), through the Application Load Balancer (which distributes traffic across availability zones), to the API Gateway (which authenticates the user and routes to the search service), and finally to the search service (which queries Elasticsearch and returns ranked results). The entire journey takes less than 200 milliseconds end-to-end, with each hop contributing 5-30 milliseconds of latency.
The write path is equally optimized. When a customer adds an item to their cart, the request flows through the same edge infrastructure to the API Gateway, which routes to the cart service. The cart service checks real-time inventory via a synchronous gRPC call to the inventory service (sub-5ms within the same region), writes to Redis (1-3ms), and publishes an event to Kafka (5-10ms asynchronously). The total cart add operation completes in under 50 milliseconds. The Kafka event triggers downstream processing: analytics aggregation, recommendation model updates, and inventory snapshot synchronization. This event-driven approach keeps the synchronous write path fast while ensuring all downstream systems eventually receive the update.
2. High-Level Architecture Overview
Amazon's e-commerce platform follows a microservices architecture with over 100 distinct services communicating through a combination of synchronous REST and gRPC calls for user-facing queries and asynchronous Kafka event streams for data propagation. The architecture is organized into three tiers: the edge tier (CDN, WAF, load balancers), the application tier (hundreds of microservices behind API Gateway), and the data tier (DynamoDB, RDS, ElastiCache, Elasticsearch, S3). Each tier is independently scalable and deployable, with cell-based isolation ensuring that a failure in one customer segment does not cascade to others.
The fundamental architectural principle at Amazon is you build it, you own it. Each microservice team owns their service's code, infrastructure, on-call rotations, and performance budgets. Services communicate through well-defined API contracts (REST for synchronous, Kafka for asynchronous), and data ownership is strict: no service reads another service's database directly. This ownership model enables thousands of engineers to work independently without coordination bottlenecks while maintaining system-wide reliability through standardized operational practices.
| Layer | Technology | Purpose |
|---|---|---|
| CDN | CloudFront (200+ edge locations) | Static assets, product images, cached pages |
| WAF | AWS WAF + Shield Advanced | DDoS protection, bot detection, rate limiting |
| Load Balancer | Application Load Balancer | TLS termination, path-based routing, health checks |
| API Gateway | Custom Kong-based gateway | Authentication, rate limiting, request routing, API versioning |
| Services | Containerized (.NET, Java, Python) | Business logic, orchestrated via ECS/EKS |
| Primary DB | DynamoDB (Global Tables) | Products, users, inventory, cart items |
| Relational DB | Aurora PostgreSQL | Orders, payments, financial records (ACID) |
| Cache | ElastiCache Redis Cluster | Sessions, cart hot data, search results, rate limiting |
| Search | Elasticsearch (OpenSearch) | Product search, faceted navigation, autocomplete |
| Object Storage | S3 | Product images, recommendation models, backups |
| Event Bus | Amazon MSK (Kafka) | Async communication, event sourcing, data pipeline |
C#
public class AmazonApiGateway
{
private readonly Dictionary<string, string> _routeTable = new()
{
["/api/v1/products/*"] = "product-service",
["/api/v1/search"] = "search-service",
["/api/v1/cart/*"] = "cart-service",
["/api/v1/orders/*"] = "order-service",
["/api/v1/payments/*"] = "payment-service",
["/api/v1/recommendations/*"]= "recommendation-service",
["/api/v1/auth/*"] = "auth-service",
["/api/v1/sellers/*"] = "seller-service",
};
public async Task<HttpResponseMessage> RouteAsync(HttpRequestMessage request)
{
var path = request.RequestUri.AbsolutePath;
var targetService = _routeTable
.FirstOrDefault(kvp => path.StartsWith(kvp.Key.Replace("/*", "")))
.Value;
if (targetService == null)
return new HttpResponseMessage(HttpStatusCode.NotFound);
var authHeader = request.Headers.Authorization;
if (authHeader != null)
{
var claims = await ValidateTokenAsync(authHeader.Parameter);
request.Headers.Add("X-User-Id", claims.UserId);
request.Headers.Add("X-User-Tier", claims.MembershipTier);
}
var rateLimitKey = $"rl:{claims?.UserId ?? "anon"}";
if (!await _rateLimiter.IsAllowedAsync(rateLimitKey, 1000, TimeSpan.FromMinutes(1)))
return new HttpResponseMessage(HttpStatusCode.TooManyRequests);
return await ForwardToServiceAsync(targetService, request);
}
}3. Product Catalog and Database Design
The product catalog is the backbone of Amazon's e-commerce platform. It must serve billions of product records with sub-100ms read latency while supporting complex attribute schemas that vary dramatically across categories. A laptop has CPU, RAM, and screen size attributes; a book has ISBN, page count, and author; clothing has size, color, and fabric. This schema variability demands a flexible document store rather than a rigid relational schema. Amazon uses DynamoDB with a single-table design pattern where product metadata, descriptions, images, and variants are stored as separate items linked by product ID, enabling independent access patterns without joins.
Product Data Model
Each product is decomposed into multiple DynamoDB items to optimize for different access patterns. The base item (title, price, rating, stock status) is read on every product page view. The description item (long-form text, specifications) is loaded on demand. The image item (CDN URLs for multiple resolutions) is cached aggressively at the edge. The variant item (size/color matrix with per-variant ASIN, price, and stock) enables the variant selector on the product page. This decomposition means a product page view reads only 1-2 small DynamoDB items instead of loading the entire product blob.
C#
public class ProductCatalogItem
{
[DynamoDBHashKey("PK")]
public string PartitionKey { get; set; }
[DynamoDBRangeKey("SK")]
public string SortKey { get; set; }
public string ProductId { get; set; }
public string Title { get; set; }
public string Category { get; set; }
public string Brand { get; set; }
public decimal Price { get; set; }
public decimal ListPrice { get; set; }
public double Rating { get; set; }
public int ReviewCount { get; set; }
public bool InStock { get; set; }
public string SellerId { get; set; }
public bool IsPrime { get; set; }
public bool IsFBA { get; set; }
public long SalesVelocity30d { get; set; }
public int Version { get; set; }
public string Description { get; set; }
public Dictionary<string, string> Specifications { get; set; }
public string VariantId { get; set; }
public string ASIN { get; set; }
public Dictionary<string, string> Attributes { get; set; }
public int VariantStock { get; set; }
public decimal VariantPrice { get; set; }
}
public class ProductCatalogService
{
private readonly IAmazonDynamoDB _dynamoDb;
private readonly IDistributedCache _cache;
public async Task<ProductCatalogItem> GetProductAsync(string productId)
{
var cacheKey = $"product:meta:{productId}";
var cached = await _cache.GetStringAsync(cacheKey);
if (cached != null)
return JsonSerializer.Deserialize<ProductCatalogItem>(cached);
var request = new QueryRequest
{
TableName = "ProductCatalog",
KeyConditionExpression = "PK = :pk AND SK = :sk",
ExpressionAttributeValues = new Dictionary<string, AttributeValue>
{
[":pk"] = new($"PRODUCT#{productId}"),
[":sk"] = new("META")
}
};
var response = await _dynamoDb.QueryAsync(request);
var item = response.Items.FirstOrDefault();
if (item == null) return null;
var product = MapToProductCatalogItem(item);
await _cache.SetStringAsync(cacheKey,
JsonSerializer.Serialize(product),
new DistributedCacheEntryOptions
{
AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(5)
});
return product;
}
public async Task<List<ProductVariant>> GetVariantsAsync(string productId)
{
var request = new QueryRequest
{
TableName = "ProductCatalog",
KeyConditionExpression = "PK = :pk AND begins_with(SK, :skPrefix)",
ExpressionAttributeValues = new Dictionary<string, AttributeValue>
{
[":pk"] = new($"PRODUCT#{productId}"),
[":skPrefix"] = new("VARIANT#")
}
};
var response = await _dynamoDb.QueryAsync(request);
return response.Items.Select(MapToProductVariant).ToList();
}
}Category-Specific Attributes
Different product categories require different attribute schemas. Amazon handles this with a category metadata store that defines which attributes are required, optional, and filterable for each category.
| Category | Required Attributes | Faceted Filters | Special Handling |
|---|---|---|---|
| Electronics | Brand, Model, Warranty, Power | Brand, Price, Rating, Prime, Weight | Technical specs comparison table |
| Books | ISBN, Author, Publisher, Pages | Author, Genre, Format | Look Inside preview, X-Ray |
| Clothing | Size, Color, Material, Fit | Size, Color, Brand, Price, Discount | Size chart, Virtual try-on |
| Grocery | Weight, Expiry, Dietary Info | Diet, Brand, Price per unit | Freshness guarantee, Subscribe and Save |
| Home and Garden | Dimensions, Material, Assembly | Room, Style, Color, Price, Rating | AR visualization for furniture |
| Software | License Type, Platform, Version | Platform, Price, Rating | Digital delivery, activation keys |
4. Search and Discovery Engine
Amazon's search engine processes over 100,000 queries per second and must return relevant, personalized results within 200 milliseconds. The search pipeline transforms a user's natural language query into a ranked list of products through a multi-stage process: query understanding (spell correction, tokenization, synonym expansion), retrieval (Elasticsearch boolean query with filters), ranking (learning-to-rank model combining hundreds of signals), and post-processing (diversity, deduplication, sponsored injection). The search index is rebuilt daily from a snapshot of the product catalog, with real-time updates propagated via Kafka for products with price or stock changes.
Query Processing Pipeline
When a user types wireless bluetooth headphones noise cancelling into the search bar, the query processing pipeline performs several transformations before the query reaches Elasticsearch. First, spell correction fixes typos. Second, tokenization splits the query into individual terms. Third, synonym expansion adds related terms (bluetooth also matches wireless, noise cancelling also matches ANC and active noise cancellation). Fourth, intent classification determines the query type: product search, brand search, or category browse. Fifth, personalization injects the user's known preferences (preferred brands, price range, past purchases).
C#
public class SearchPipeline
{
private readonly ISpellCorrector _spellCorrector;
private readonly ISynonymExpander _synonymExpander;
private readonly IIntentClassifier _intentClassifier;
private readonly IElasticsearchClient _esClient;
private readonly IRankingModel _rankingModel;
private readonly ICache _cache;
public async Task<SearchResult> SearchAsync(SearchRequest request)
{
var cacheKey = $"search:{request.Query}:{request.FiltersHash}:{request.UserId}";
var cached = await _cache.GetAsync<SearchResult>(cacheKey);
if (cached != null) return cached;
var correctedQuery = await _spellCorrector.CorrectAsync(request.Query);
var expandedTerms = await _synonymExpander.ExpandAsync(correctedQuery);
var intent = await _intentClassifier.ClassifyAsync(request.Query);
var esQuery = BuildElasticsearchQuery(expandedTerms, request.Filters, intent);
var rawResults = await _esClient.SearchAsync<ProductDocument>(s => s
.Index("products")
.Query(esQuery)
.Size(500)
.Sort(so => so.Descending("_score"))
.Source(src => src.Excludes(e => e.Field(f => f.Description)))
);
var userContext = await GetUserContextAsync(request.UserId);
var rankedProducts = await _rankingModel.RankAsync(
rawResults.Documents,
request.Query,
userContext,
intent
);
var diversified = ApplyDiversityRules(rankedProducts, request.Page);
var sponsored = await InjectSponsoredProductsAsync(diversified, request.Query, 3);
var result = new SearchResult
{
Products = diversified,
SponsoredProducts = sponsored,
TotalCount = rawResults.Total,
QueryCorrection = correctedQuery != request.Query ? correctedQuery : null,
Facets = await GetFacetsAsync(rawResults, request.Filters)
};
await _cache.SetAsync(cacheKey, result, TimeSpan.FromSeconds(60));
return result;
}
private object BuildElasticsearchQuery(List<string> terms, SearchFilters filters, QueryIntent intent)
{
var mustClauses = new List<object>
{
new { multi_match = new
{
query = string.Join(" ", terms),
fields = new[] { "title^5", "brand^3", "category^2", "description^1", "tags^2" },
type = "best_fields",
fuzziness = "AUTO"
}}
};
var filterClauses = new List<object>
{
new { term = new { inStock = true } }
};
if (filters.PriceMin.HasValue)
filterClauses.Add(new { range = new { price = new { gte = filters.PriceMin } } });
if (filters.PriceMax.HasValue)
filterClauses.Add(new { range = new { price = new { lte = filters.PriceMax } } });
if (filters.Brands?.Any() == true)
filterClauses.Add(new { terms = new { brand = filters.Brands } });
if (filters.PrimeOnly)
filterClauses.Add(new { term = new { isPrime = true } });
return new { bool = new { must = mustClauses, filter = filterClauses } };
}
}Ranking Signals
Amazon's ranking algorithm considers over 200 signals to determine the order of search results. The most important signals include text relevance (how well the product matches the query terms), sales velocity (recent purchase frequency), conversion rate (percentage of viewers who purchase), customer rating (weighted average review score), Prime eligibility (Prime products rank higher for Prime members), seller rating (FBA sellers get a boost), and freshness (newer products get a temporary boost).
| Signal | Weight | Update Frequency | Data Source |
|---|---|---|---|
| Text relevance (BM25) | 30% | On index rebuild (daily) | Elasticsearch |
| Sales velocity (30-day) | 20% | Daily batch job | Order pipeline |
| Click-through rate | 15% | Hourly aggregation | Impression and click logs |
| Conversion rate | 15% | Daily batch job | Order and impression logs |
| Customer rating | 10% | Real-time | Review service |
| Prime eligibility | 5% | Real-time | Inventory service |
| Seller rating | 3% | Weekly | Seller performance |
| Product freshness | 2% | Daily | Product catalog |
5. Shopping Cart with Cross-Device Persistence
Amazon's shopping cart is one of the most critical and complex components of the e-commerce platform. It must persist across sessions (a guest adds items on mobile, returns on desktop and finds them), merge seamlessly when a guest logs in, reflect real-time inventory status, handle price fluctuations between add and checkout, and support the save for later and buy again features. The cart service is optimized for write-heavy workloads with low-latency reads, using Redis as the primary store for active cart data and DynamoDB as the durable persistence layer.
Cart Data Flow
C#
public class CartService
{
private readonly IConnectionMultiplexer _redis;
private readonly IAmazonDynamoDB _dynamoDb;
private readonly IKafkaProducer _kafka;
private readonly IInventoryClient _inventoryClient;
public async Task<CartResponse> AddItemAsync(string userId, string sessionId,
CartItemRequest item)
{
var cartKey = userId != null
? $"cart:user:{userId}"
: $"cart:guest:{sessionId}";
var stock = await _inventoryClient.GetStockAsync(
item.ProductId, item.VariantId, item.DeliveryPincode);
if (stock.AvailableQuantity < item.Quantity)
{
return new CartResponse
{
Success = false,
ErrorMessage = $"Only {stock.AvailableQuantity} left in stock",
MaxQuantity = stock.AvailableQuantity
};
}
var currentPrice = await GetProductPriceAsync(item.ProductId, item.VariantId);
var db = _redis.GetDatabase();
var cartItem = new CartItemEntity
{
ProductId = item.ProductId,
VariantId = item.VariantId,
Quantity = item.Quantity,
PriceAtAdd = currentPrice,
AddedAt = DateTimeOffset.UtcNow,
SellerId = stock.SellerId,
IsPrimeEligible = stock.IsPrime
};
var fieldKey = $"{item.ProductId}:{item.VariantId}";
await db.HashSetAsync(cartKey, fieldKey, JsonSerializer.Serialize(cartItem));
if (userId == null)
await db.KeyExpireAsync(cartKey, TimeSpan.FromDays(7));
await _kafka.ProduceAsync("cart_events", new CartEvent
{
Type = CartEventType.ItemAdded,
UserId = userId,
SessionId = sessionId,
Item = cartItem,
Timestamp = DateTimeOffset.UtcNow
});
return await GetCartSummaryAsync(cartKey);
}
public async Task<CartMergeResult> MergeCartsOnLoginAsync(string userId, string sessionId)
{
var guestKey = $"cart:guest:{sessionId}";
var userKey = $"cart:user:{userId}";
var guestItems = await _redis.HashGetAllAsync(guestKey);
var merged = new CartMergeResult { ItemsAdded = 0, ItemsSkipped = 0 };
foreach (var entry in guestItems)
{
var exists = await _redis.HashExistsAsync(userKey, entry.Name);
if (!exists)
{
await _redis.HashSetAsync(userKey, entry.Name, entry.Value);
merged.ItemsAdded++;
}
else
{
merged.ItemsSkipped++;
}
}
await _redis.KeyDeleteAsync(guestKey);
return merged;
}
}Cart Pricing Considerations
Amazon's cart must handle a subtle but critical challenge: the price of an item can change between when a user adds it to their cart and when they check out. Amazon's policy is to honor the lower of the two prices. If a price drops between add-to-cart and checkout, the customer pays the lower price. If a price increases, the cart displays the new price but allows checkout at the original add-to-cart price for a configurable grace period (typically 15 minutes).
| Scenario | Cart Behavior | Checkout Price |
|---|---|---|
| Price drops after add-to-cart | Show Price dropped badge | Lower price (current price) |
| Price rises within 15 min of add | Show original add price | Original add-to-cart price (locked) |
| Price rises after 15 min grace period | Show updated price with warning | Current price at checkout |
| Item goes out of stock | Show Currently unavailable with Save for later | Cannot proceed to checkout |
| Item becomes backorder | Show Available in X days with option to proceed | Add-to-cart price |
| Coupon applied expires before checkout | Show Coupon expired banner | Price without coupon |
6. User Authentication and Account Management
Amazon's authentication system must handle 300 million plus user accounts with seamless single sign-on across web, mobile apps, Kindle devices, Fire TV, Alexa, and third-party apps using Amazon Login. The system supports multiple authentication methods: email/password, phone number OTP, social login (Google, Apple, Facebook), and biometric authentication on mobile devices. Sessions are managed via JWT access tokens (15-minute expiry) with refresh tokens (30-day expiry) stored in HttpOnly secure cookies. The auth service is one of the most security-critical components, handling billions of authentication requests daily with zero tolerance for account takeover vulnerabilities.
C#
public class AuthService
{
private readonly IPasswordHasher _hasher;
private readonly ITokenIssuer _tokenIssuer;
private readonly IAmazonDynamoDB _dynamoDb;
private readonly IMfaService _mfaService;
private readonly IFraudDetector _fraudDetector;
public async Task<AuthResult> AuthenticateAsync(LoginRequest request)
{
var riskScore = await _fraudDetector.AssessLoginRiskAsync(
request.Email, request.IpAddress, request.DeviceFingerprint);
if (riskScore > 0.8)
return AuthResult.Fraudulent("Suspicious login detected.");
var user = await GetUserByEmailAsync(request.Email);
if (user == null)
{
await _hasher.HashPasswordAsync("dummy_password_to_prevent_timing");
return AuthResult.InvalidCredentials("Invalid email or password.");
}
var verificationResult = _hasher.VerifyHashedPassword(
user.PasswordHash, request.Password);
if (verificationResult == PasswordVerificationResult.Failed)
{
user.FailedLoginAttempts++;
if (user.FailedLoginAttempts >= 5)
{
await LockAccountAsync(user.UserId, TimeSpan.FromMinutes(30));
await SendSecurityAlertAsync(user);
}
await UpdateUserAsync(user);
return AuthResult.InvalidCredentials("Invalid email or password.");
}
if (user.MfaEnabled && riskScore > 0.3)
{
var mfaToken = await _mfaService.SendOtpAsync(user);
return AuthResult.MfaRequired(mfaToken.SessionId);
}
var accessToken = await _tokenIssuer.IssueAccessTokenAsync(user, request.DeviceInfo);
var refreshToken = await _tokenIssuer.IssueRefreshTokenAsync(user, request.DeviceInfo);
await RecordLoginAsync(user.UserId, request.IpAddress, request.DeviceFingerprint);
return AuthResult.Success(accessToken, refreshToken, user);
}
}Session Management Across Devices
Amazon supports simultaneous sessions across multiple devices with per-device session management. Each session is tracked in Redis with device metadata (device type, OS, browser, location). Users can view and revoke active sessions from their account settings.
| Auth Method | Security Level | Use Case | Token Lifetime |
|---|---|---|---|
| Email + Password | Standard | Regular login | Access: 15min, Refresh: 30 days |
| Phone OTP | High | High-risk transactions | Access: 5min, No refresh |
| Biometric (Face/Touch) | High | Mobile app quick login | Access: 15min, Refresh: 30 days |
| SSO (Amazon Login) | Standard | Third-party apps | Access: 1hr, Refresh: 90 days |
| Hardware MFA Key | Very High | Seller accounts, AWS | Access: 15min, Refresh: requires MFA |
| Passkey / FIDO2 | Very High | Passwordless login | Access: 1hr, Refresh: 30 days |
7. Order Management Pipeline
The order management pipeline is the most critical path in the entire e-commerce system. Every millisecond of latency and every nines of reliability directly impacts Amazon's bottom line. The pipeline transforms a cart checkout into a confirmed order through a multi-step saga: inventory reservation, payment authorization, order creation, fulfillment center assignment, and shipment tracking. Each step is independently retryable and compensatable, with dead letter queues for orders that fail after exhausting retries. The order service is implemented as an event-sourced system where every state transition is recorded as an immutable event in Kafka.
Order State Machine
C#
public class OrderService
{
private readonly IInventoryClient _inventoryClient;
private readonly IPaymentClient _paymentClient;
private readonly IKafkaProducer _kafka;
private readonly IFulfillmentClient _fulfillmentClient;
public async Task<OrderResult> PlaceOrderAsync(CheckoutRequest request)
{
var order = await CreatePendingOrderAsync(request);
try
{
var reservations = new List<InventoryReservation>();
foreach (var item in request.Items)
{
var reservation = await _inventoryClient.ReserveAsync(
order.OrderId, item.ProductId, item.VariantId,
item.Quantity, request.ShippingAddress.Pincode);
if (reservation.Status == ReservationStatus.Failed)
{
await CompensateReservationsAsync(reservations);
await UpdateOrderStatusAsync(order.OrderId, OrderStatus.InsufficientInventory);
return OrderResult.Failed("Some items are no longer available.");
}
reservations.Add(reservation);
}
var paymentResult = await _paymentClient.AuthorizeAsync(new PaymentRequest
{
OrderId = order.OrderId,
Amount = CalculateTotal(request, reservations),
Currency = "USD",
PaymentMethodId = request.PaymentMethodId,
BillingAddress = request.BillingAddress
});
if (!paymentResult.Success)
{
await CompensateReservationsAsync(reservations);
await UpdateOrderStatusAsync(order.OrderId, OrderStatus.PaymentFailed);
return OrderResult.Failed("Payment could not be processed.");
}
await ConfirmOrderAsync(order.OrderId, paymentResult.TransactionId);
foreach (var reservation in reservations)
{
await _inventoryClient.CommitReservationAsync(reservation.ReservationId);
}
await _fulfillmentClient.AssignToFulfillmentCenterAsync(order.OrderId);
await _kafka.ProduceAsync("order_events", new OrderEvent
{
Type = OrderEventType.OrderConfirmed,
OrderId = order.OrderId,
UserId = request.UserId,
Items = request.Items,
Total = paymentResult.Amount,
Timestamp = DateTimeOffset.UtcNow
});
return OrderResult.Success(order);
}
catch (Exception ex)
{
await CompensateReservationsAsync(reservations);
await _paymentClient.VoidAsync(order.OrderId);
await UpdateOrderStatusAsync(order.OrderId, OrderStatus.Failed);
throw;
}
}
}Order Splitting and Multi-FC Fulfillment
When an order contains items from different sellers or items stored in different fulfillment centers, the order is automatically split into multiple shipments. Each shipment is tracked independently with its own tracking number, estimated delivery date, and shipping status.
| Order Status | Description | Customer Notification | Duration |
|---|---|---|---|
| Cart | Items in shopping cart | None | Indefinite |
| Pending | Checkout initiated, processing | None | 0-5 seconds |
| Confirmed | Payment successful, order placed | Email + App push | Instant |
| Picking | FC worker scanning items | In-app status | 1-4 hours |
| Packed | Items packed in shipping box | In-app status | 1-2 hours |
| Shipped | Package handed to carrier | Email + SMS + Tracking number | Same day or next |
| In Transit | Package moving through carrier | Daily tracking updates | 1-5 days |
| Delivered | Package delivered | Email + Push + Photo proof | Done |
| Returned | Item received at FC | Email with refund status | 3-7 days |
8. Payment Processing and Fraud Detection
Amazon processes billions of dollars in transactions annually through a payment system that must balance speed, security, and reliability. The payment service handles authorization (verifying funds are available), capture (charging the card), settlement (transferring funds to sellers), and refund processing. It supports multiple payment methods including credit/debit cards, Amazon Pay balance, gift cards, EMI (equated monthly installments), UPI, and net banking. Every transaction passes through a real-time fraud detection pipeline that analyzes over 100 risk signals to prevent unauthorized purchases while minimizing false positives that would reject legitimate customers.
C#
public class PaymentService
{
private readonly IFraudDetector _fraudDetector;
private readonly IPaymentGateway _gateway;
private readonly IGiftCardService _giftCardService;
public async Task<PaymentResult> ProcessPaymentAsync(PaymentRequest request)
{
var fraudResult = await _fraudDetector.AnalyzeAsync(new FraudContext
{
UserId = request.UserId,
Amount = request.Amount,
Currency = request.Currency,
PaymentMethod = request.PaymentMethodId,
IpAddress = request.IpAddress,
DeviceFingerprint = request.DeviceInfo,
ShippingAddress = request.ShippingAddress,
OrderHistory = await GetUserOrderHistoryAsync(request.UserId, 30)
});
if (fraudResult.RiskScore > 0.9)
{
await FlagForManualReviewAsync(request);
return PaymentResult.Declined("Transaction flagged for review.");
}
if (fraudResult.RiskScore > 0.7)
{
var stepUp = await RequireStepUpAuthenticationAsync(request);
if (!stepUp.Completed)
return PaymentResult.Declined("Authentication failed.");
}
var splits = CalculatePaymentSplits(request);
var transactions = new List<TransactionRecord>();
decimal remainingAmount = request.Amount;
foreach (var split in splits)
{
TransactionRecord txn;
if (split.Method == PaymentMethod.GiftCard)
{
txn = await _giftCardService.DeductAsync(split.GiftCardId, split.Amount);
}
else
{
txn = await _gateway.AuthorizeAsync(new GatewayRequest
{
PaymentMethodId = split.PaymentToken,
Amount = split.Amount,
Currency = request.Currency,
OrderId = request.OrderId,
ThreeDSecure = fraudResult.RiskScore > 0.5
});
}
if (!txn.Success)
{
await RollbackTransactionsAsync(transactions);
return PaymentResult.Declined($"Payment failed: {txn.ErrorMessage}");
}
transactions.Add(txn);
remainingAmount -= split.Amount;
}
await RecordPaymentAsync(request.OrderId, transactions);
return PaymentResult.Success(transactions.Sum(t => t.Amount), transactions);
}
private List<PaymentSplit> CalculatePaymentSplits(PaymentRequest request)
{
var splits = new List<PaymentSplit>();
decimal remaining = request.Amount;
if (request.GiftCardIds?.Any() == true)
{
foreach (var gcId in request.GiftCardIds)
{
var balance = await _giftCardService.GetBalanceAsync(gcId);
var deduction = Math.Min(balance, remaining);
splits.Add(new PaymentSplit
{
Method = PaymentMethod.GiftCard,
GiftCardId = gcId,
Amount = deduction
});
remaining -= deduction;
}
}
if (remaining > 0)
{
splits.Add(new PaymentSplit
{
Method = PaymentMethod.Card,
PaymentToken = request.PaymentToken,
Amount = remaining
});
}
return splits;
}
}Fraud Detection Signals
Amazon's fraud detection system analyzes over 100 signals in real-time for every transaction. The signals span multiple dimensions: device intelligence, behavioral biometrics, transaction patterns, and network analysis. The fraud model is a deep neural network trained on billions of historical transactions, retrained daily with new labeled data from the manual review team.
| Fraud Signal | Risk Indicator | Weight | Action |
|---|---|---|---|
| New device + high-value order | +0.3 risk | High | Require step-up authentication |
| Shipping to known fraud address | +0.5 risk | Critical | Block or manual review |
| Velocity: 5+ orders in 1 hour | +0.4 risk | High | Temporarily hold orders |
| Card BIN mismatch with IP geo | +0.2 risk | Medium | Request 3D Secure verification |
| Multiple accounts, same device | +0.3 risk | High | Link accounts, review |
| Abnormal time of purchase | +0.1 risk | Low | Combine with other signals |
| Gift card bulk purchase | +0.4 risk | High | Limits and verification |
| Known return abuse pattern | +0.3 risk | Medium | Restrict return window |
9. Inventory Management and Anti-Overselling
Inventory management at Amazon is a distributed systems problem of the highest order. With 200+ fulfillment centers, each holding millions of items, and millions of concurrent shoppers during peak events, preventing overselling requires sophisticated coordination. Amazon uses a two-phase reservation protocol with optimistic locking to ensure inventory consistency without sacrificing checkout speed. The system reserves stock during checkout, holds it for a configurable TTL (typically 15 minutes), and commits the decrement only after payment succeeds. If the customer abandons checkout or payment fails, the reservation expires and stock becomes available again.
C#
public class InventoryService
{
private readonly IAmazonDynamoDB _dynamoDb;
private readonly IKafkaProducer _kafka;
public async Task<ReservationResult> ReserveInventoryAsync(
string orderId, string productId, string variantId,
int quantity, string deliveryPincode)
{
var fc = await FindOptimalFCAsync(deliveryPincode, productId, quantity);
if (fc == null)
return ReservationResult.NoStockAvailable("Item not available for your location.");
var inventoryKey = $"INV#{fc.Id}#{productId}#{variantId}";
for (int retry = 0; retry < 3; retry++)
{
var response = await _dynamoDb.GetItemAsync(new GetItemRequest
{
TableName = "Inventory",
Key = new Dictionary<string, AttributeValue>
{
["PK"] = new(inventoryKey),
["SK"] = new("STOCK")
},
ConsistentRead = true
});
if (response.Item == null)
return ReservationResult.NoStockAvailable("Item not found.");
var available = int.Parse(response.Item["available_quantity"].N);
var version = int.Parse(response.Item["version"].N);
var reservedAt = response.Item.ContainsKey("reserved_at")
? DateTime.Parse(response.Item["reserved_at"].S)
: (DateTime?)null;
if (reservedAt.HasValue && DateTime.UtcNow - reservedAt.Value < TimeSpan.FromMinutes(15))
continue;
if (available < quantity)
return ReservationResult.InsufficientStock($"Only {available} units available.");
try
{
await _dynamoDb.UpdateItemAsync(new UpdateItemRequest
{
TableName = "Inventory",
Key = new Dictionary<string, AttributeValue>
{
["PK"] = new(inventoryKey),
["SK"] = new("STOCK")
},
UpdateExpression = "SET available_quantity = available_quantity - :qty, " +
"reserved_quantity = reserved_quantity + :qty, " +
"version = version + :one, " +
"reserved_at = :now, reserved_by = :orderId",
ConditionExpression = "version = :expectedVersion AND available_quantity >= :qty",
ExpressionAttributeValues = new Dictionary<string, AttributeValue>
{
[":qty"] = new N(quantity.ToString()),
[":one"] = new N("1"),
[":now"] = new S(DateTime.UtcNow.ToString("o")),
[":orderId"] = new S(orderId),
[":expectedVersion"] = new N(version.ToString())
}
});
return ReservationResult.Success(fc.Id, inventoryKey);
}
catch (ConditionalCheckFailedException)
{
continue;
}
}
return ReservationResult.ConcurrencyFailure("Unable to reserve inventory. Please try again.");
}
}Cross-FC Inventory Rebalancing
Amazon continuously rebalances inventory across fulfillment centers based on demand forecasting. A daily batch job analyzes purchase patterns by geographic region and recommends stock transfers between FCs. The forecasting model uses time-series analysis (Prophet), seasonal patterns, upcoming events (Black Friday, Prime Day), and regional trend data to predict demand 30 days out.
| Inventory State | Description | Available for New Orders |
|---|---|---|
| On Shelf | Physically in FC, not reserved | Yes |
| Reserved | Held for in-progress checkout (TTL: 15 min) | No |
| Committed | Order confirmed, awaiting pick | No |
| In Pick | Worker actively picking from shelf | No |
| Packed | In shipping box, ready for carrier | No |
| In Transit | On truck to customer or between FCs | No |
| Inbound | Receiving from supplier or FBA shipment | Not yet |
| Returned | Returned item being inspected | After QC pass |
| Damaged | Unsellable, awaiting disposal | No |
10. Recommendation Engine
Amazon's recommendation engine is responsible for generating 35% of the company's total revenue, making it one of the most commercially valuable machine learning systems ever built. The engine powers multiple surfaces: Recommended for you on the homepage, Customers who bought this also bought on product pages, Frequently bought together for cross-selling, Inspired by your browsing history in the Your Recently Viewed widget, and Subscribe and Save suggestions. The system combines offline batch computation (Spark-based collaborative filtering updated daily) with real-time signal blending (Redis-backed recent activity) to deliver personalized results with sub-50ms serving latency.
Recommendation Algorithms
The recommendation system uses a multi-algorithm ensemble approach. Item-to-item collaborative filtering is the backbone algorithm, pre-computed offline on Spark. For each product A, the system finds the top 50 products B where customers who purchased A also purchased B, weighted by co-purchase frequency and recency. The co-purchase matrix is enormous: 2 billion products with 50 neighbors each equals 100 billion edges, and is stored in a sharded Elasticsearch index for fast retrieval.
C#
public class RecommendationService
{
private readonly IRedisCluster _redis;
private readonly IProductSimilarityIndex _similarityIndex;
private readonly IUserActivityTracker _activityTracker;
private readonly IPersonalizationModel _personalizationModel;
public async Task<List<RecommendedProduct>> GetAlsoBoughtAsync(
string productId, int limit = 10)
{
var cacheKey = $"rec:also_bought:{productId}";
var cached = await _redis.ListRangeAsync(cacheKey, 0, limit - 1);
if (cached.Length > 0)
return cached.Select(c => JsonSerializer.Deserialize<RecommendedProduct>(c)).ToList();
var similarProducts = await _similarityIndex.QueryAsync(productId, limit);
await _redis.ListRightPushAsync(cacheKey,
similarProducts.Select(p => (RedisValue)JsonSerializer.Serialize(p)).ToArray());
await _redis.KeyExpireAsync(cacheKey, TimeSpan.FromHours(1));
return similarProducts;
}
public async Task<PersonalizedRecommendations> GetPersonalizedFeedAsync(
string userId, int page = 1)
{
var context = new RecommendationContext
{
UserId = userId,
RecentViews = await _activityTracker.GetRecentViewsAsync(userId, 50),
CartItems = await _activityTracker.GetCartItemsAsync(userId),
PurchaseHistory = await _activityTracker.GetPurchaseHistoryAsync(userId, 100),
WishlistItems = await _activityTracker.GetWishlistAsync(userId)
};
var candidateTasks = new List<Task<List<CandidateProduct>>>
{
GetCollaborativeFilterCandidatesAsync(context),
GetContentBasedCandidatesAsync(context),
GetTrendingCandidatesAsync(),
GetCrossSellCandidatesAsync(context.CartItems),
GetRecentlyViewedSimilarAsync(context.RecentViews)
};
await Task.WhenAll(candidateTasks);
var allCandidates = candidateTasks
.SelectMany(t => t.Result)
.GroupBy(c => c.ProductId)
.Select(g => g.First())
.ToList();
var ranked = await _personalizationModel.RankAsync(allCandidates, context);
var filtered = ranked
.Where(p => !context.PurchaseHistory.Contains(p.ProductId))
.Where(p => p.InStock)
.Skip((page - 1) * 20)
.Take(20)
.ToList();
return new PersonalizedRecommendations
{
Items = filtered,
Algorithms = new[] { "collaborative_filtering", "content_based", "trending", "cross_sell" },
CacheHit = false
};
}
public async Task ComputeItemSimilaritiesAsync()
{
var orders = await _orderDb.QueryAsync<OrderRecord>(
"SELECT order_id, product_ids FROM orders WHERE order_date >= @cutoff",
new { cutoff = DateTime.UtcNow.AddDays(-90) });
var coPurchaseCounts = new Dictionary<(string, string), long>();
foreach (var order in orders)
{
var products = order.ProductIds;
for (int i = 0; i < products.Count; i++)
{
for (int j = i + 1; j < products.Count; j++)
{
var key = string.Compare(products[i], products[j]) < 0
? (products[i], products[j])
: (products[j], products[i]);
coPurchaseCounts.TryGetValue(key, out var count);
coPurchaseCounts[key] = count + 1;
}
}
}
var similarities = coPurchaseCounts
.Where(kvp => kvp.Value >= 10)
.Select(kvp => new ProductSimilarity
{
ProductA = kvp.Key.Item1,
ProductB = kvp.Key.Item2,
Score = ComputeJaccardSimilarity(kvp.Key.Item1, kvp.Key.Item2, kvp.Value),
CoPurchases = kvp.Value
})
.GroupBy(s => s.ProductA)
.SelectMany(g => g.OrderByDescending(s => s.Score).Take(50))
.ToList();
await _similarityIndex.BulkInsertAsync(similarities);
}
}| Algorithm | Data Source | Update Frequency | Coverage | Strength |
|---|---|---|---|---|
| Item-to-Item CF | 90-day order logs | Daily (Spark) | 80% of products | Proven 35% revenue lift |
| Frequently Bought Together | Order data | Daily (Spark) | Products with 50+ orders | Cross-sell basket optimization |
| Content-Based | Product attributes | Weekly (NLP model) | All products | Works for new/cold products |
| Trending | Real-time sales velocity | Hourly | Top 10K products | Captures viral/holiday trends |
| Personalized LTR | All signals combined | Real-time serving | Active users | Highest relevance |
| Deep Learning (DLRM) | All signals combined | Weekly retrain | Top 100M users | Complex interactions |
11. Fulfillment and Warehouse Automation
Amazon's fulfillment system is the physical backbone of the e-commerce operation, transforming digital orders into shipped packages through a choreographed dance of humans, robots, and algorithms. After an order is confirmed, it enters a fulfillment pipeline that spans multiple stages: FC assignment, pick list generation, item picking (often via Kiva robots), packing (with box-size optimization), carrier selection, and last-mile delivery. The entire pipeline is event-driven: every barcode scan at every stage publishes an event to Kafka, which triggers downstream services including tracking updates, customer notifications, and delivery estimate recalculation.
Fulfillment Pipeline
C#
public class FulfillmentService
{
private readonly IKafkaConsumer _consumer;
private readonly IPickListOptimizer _pickOptimizer;
private readonly IBoxSelector _boxSelector;
private readonly ICarrierRouter _carrierRouter;
public async Task ProcessOrderFulfillmentAsync(OrderConfirmedEvent orderEvent)
{
var fcAssignment = await AssignToFulfillmentCenterAsync(orderEvent);
var pickList = await _pickOptimizer.GeneratePickListAsync(
fcAssignment.FulfillmentCenterId,
orderEvent.Items,
optimization: PickPathOptimization.ShortestWalk
);
var warehouseTask = new WarehouseTask
{
OrderId = orderEvent.OrderId,
FulfillmentCenterId = fcAssignment.FulfillmentCenterId,
PickList = pickList,
Priority = orderEvent.IsPrime ? TaskPriority.High : TaskPriority.Normal,
Deadline = CalculatePickDeadline(orderEvent, fcAssignment),
AssignedZone = pickList.Items.GroupBy(i => i.Zone).First().Key
};
await _warehouseDb.CreateTaskAsync(warehouseTask);
}
public async Task ProcessPackingAsync(PickCompleteEvent pickEvent)
{
var orderItems = await GetOrderItemsAsync(pickEvent.OrderId);
var itemDimensions = orderItems.Select(i => new ItemDimensions
{
ProductId = i.ProductId,
Width = i.BoxWidth,
Height = i.BoxHeight,
Depth = i.BoxDepth,
Weight = i.Weight,
IsFragile = i.IsFragile,
RequiresColdPack = i.RequiresColdPack
}).ToList();
var boxSelection = _boxSelector.SelectOptimalBox(itemDimensions);
if (boxSelection.RequiresMultipleBoxes)
{
var shipments = _boxSelector.SplitIntoShipments(itemDimensions);
foreach (var shipment in shipments)
{
var shippingLabel = await _carrierRouter.GetShippingLabelAsync(
pickEvent.FulfillmentCenterId,
pickEvent.DeliveryAddress,
shipment.BoxDimensions,
shipment.Weight,
pickEvent.IsPrime ? ShippingPriority.NextDay : ShippingPriority.Standard
);
await CreateShipmentAsync(pickEvent.OrderId, shipment, shippingLabel);
}
}
else
{
var shippingLabel = await _carrierRouter.GetShippingLabelAsync(
pickEvent.FulfillmentCenterId,
pickEvent.DeliveryAddress,
boxSelection.BoxDimensions,
boxSelection.TotalWeight,
pickEvent.IsPrime ? ShippingPriority.NextDay : ShippingPriority.Standard
);
await CreateShipmentAsync(pickEvent.OrderId, boxSelection, shippingLabel);
}
}
public List<PickItem> OptimizePickPath(List<PickItem> items, WarehouseLayout layout)
{
var path = new List<PickItem>();
var remaining = new List<PickItem>(items);
var currentLocation = layout.PickingStation;
while (remaining.Count > 0)
{
var nearest = remaining
.OrderBy(item => layout.GetDistance(currentLocation, item.BinLocation))
.First();
path.Add(nearest);
currentLocation = nearest.BinLocation;
remaining.Remove(nearest);
}
return path;
}
}Amazon Robotics
Amazon's fulfillment centers use over 750,000 robotic drives that autonomously navigate warehouse floors to transport shelving units to human workers. The robots operate on a grid-based navigation system with centralized fleet management. Each robot can carry up to 1,000 lbs and moves at 1.5 m/s. The robotic system reduces the average walking distance for workers from 10 miles per shift to less than 2 miles, dramatically improving picking efficiency.
| Fulfillment Stage | Average Time | Automation Level | Bottleneck |
|---|---|---|---|
| FC Assignment | 50ms | Fully automated | Cross-FC inventory lookup |
| Pick List Generation | 200ms | Fully automated | Pick path optimization (NP-hard) |
| Robot Transport | 3-5 minutes | Fully automated | Robot traffic during peak |
| Item Picking | 5-10 minutes | Human + robot assist | Worker throughput per hour |
| Packing | 3-5 minutes | Mostly automated | Fragile and odd-size items |
| Carrier Sortation | 15-30 minutes | Fully automated | Carrier pickup schedule |
| Last Mile Delivery | 1-5 days | Human drivers + DSP | Traffic, weather, distance |
12. Notification and Communication System
Amazon sends billions of notifications annually across multiple channels: email (order confirmations, shipping updates, promotional offers), SMS (delivery alerts, OTP verification), push notifications (mobile app, browser), and in-app messages (deal alerts, price drops). The notification system is built as an event-driven pipeline with channel-specific delivery guarantees. Email is fire-and-forget with retry; SMS requires at-least-once delivery with duplicate suppression; push notifications are best-effort with silent fallback to email. Each notification is templated with personalization tokens and localized for 20+ languages.
C#
public class NotificationService
{
private readonly ITemplateEngine _templateEngine;
private readonly IEmailClient _emailClient;
private readonly ISmsClient _smsClient;
private readonly IPushClient _pushClient;
private readonly IPreferenceStore _preferenceStore;
public async Task SendNotificationAsync(NotificationEvent notificationEvent)
{
var user = await GetUserPreferencesAsync(notificationEvent.UserId);
var channels = new List<NotificationChannel>();
switch (notificationEvent.Type)
{
case NotificationType.OrderConfirmed:
channels.Add(NotificationChannel.Email);
channels.Add(NotificationChannel.Push);
if (user.SmsOptIn) channels.Add(NotificationChannel.Sms);
break;
case NotificationType.Shipped:
channels.Add(NotificationChannel.Email);
channels.Add(NotificationChannel.Push);
break;
case NotificationType.Delivered:
channels.Add(NotificationChannel.Push);
if (user.SmsOptIn) channels.Add(NotificationChannel.Sms);
break;
case NotificationType.PriceDrop:
if (user.PriceDropAlerts) channels.Add(NotificationChannel.Push);
if (user.PriceDropEmails) channels.Add(NotificationChannel.Email);
break;
}
var sendTasks = channels.Select(channel => SendToChannelAsync(channel, notificationEvent, user));
await Task.WhenAll(sendTasks);
await RecordNotificationAsync(notificationEvent, channels);
}
private async Task SendToChannelAsync(NotificationChannel channel,
NotificationEvent evt, UserProfile user)
{
var dedupeKey = $"notif:{user.UserId}:{evt.Type}:{evt.EntityId}";
if (!await _dedupeStore.SetIfNotExistsAsync(dedupeKey, true, TimeSpan.FromHours(1)))
return;
var template = await _templateEngine.RenderAsync(evt.TemplateId, evt.TemplateData);
switch (channel)
{
case NotificationChannel.Email:
await _emailClient.SendAsync(new EmailMessage
{
To = user.Email,
Subject = template.Subject,
Body = template.HtmlBody,
TextBody = template.TextBody,
From = "shipping@amazon.com"
});
break;
case NotificationChannel.Sms:
await _smsClient.SendAsync(new SmsMessage
{
To = user.PhoneNumber,
Body = template.SmsBody,
SenderId = "AMAZON"
});
break;
case NotificationChannel.Push:
await _pushClient.SendAsync(new PushMessage
{
UserId = user.UserId,
Title = template.PushTitle,
Body = template.PushBody,
Data = new Dictionary<string, string>
{
["deepLink"] = template.DeepLink,
["image"] = template.ImageUrl
}
});
break;
}
}
}| Channel | Delivery Guarantee | Latency (p99) | Cost per Message | Best For |
|---|---|---|---|---|
| Email (SES) | At-least-once | 30 seconds | $0.0001 | Order confirmations, receipts, promotions |
| SMS | Exactly-once (with dedup) | 5 seconds | $0.0075 | OTP, delivery alerts, high-priority |
| Push (FCM/APNs) | Best-effort | 2 seconds | $0.00001 | Shipping updates, deal alerts |
| In-App | At-least-once | Instant | $0 | Real-time alerts, contextual messages |
| Web Push | Best-effort | 5 seconds | $0.00001 | Desktop deal alerts, back-in-stock |
13. API Gateway, Load Balancing, and Rate Limiting
Amazon's API Gateway is the single entry point for all client requests, handling authentication, authorization, rate limiting, request routing, response caching, and protocol translation. The gateway processes 10 million plus requests per second at peak, requiring extreme efficiency in request handling. It is built as a custom service on top of NGINX with Lua scripting for dynamic routing logic. The gateway maintains a service registry that maps URL paths to backend microservices, with health checks that automatically remove unhealthy instances within 30 seconds of detection.
C#
public class ApiGateway
{
private readonly ServiceRegistry _registry;
private readonly IRateLimiter _rateLimiter;
private readonly IResponseCache _cache;
private readonly IJwtValidator _jwtValidator;
public async Task<GatewayResponse> HandleRequestAsync(HttpRequest request)
{
var authResult = await AuthenticateRequestAsync(request);
if (!authResult.Authenticated && IsProtectedRoute(request.Path))
return GatewayResponse.Unauthorized("Authentication required.");
var rateLimitKey = authResult.Authenticated
? $"rl:user:{authResult.UserId}:{GetEndpointGroup(request.Path)}"
: $"rl:ip:{request.ClientIp}:{GetEndpointGroup(request.Path)}";
var rateConfig = GetRateLimitConfig(request.Path);
if (!await _rateLimiter.IsAllowedAsync(rateLimitKey, rateConfig.MaxRequests, rateConfig.Window))
return GatewayResponse.RateLimited("Rate limit exceeded.");
if (request.Method == "GET" && IsCacheableRoute(request.Path))
{
var cacheKey = $"cache:{request.Path}:{request.QueryString}";
var cached = await _cache.GetAsync<byte[]>(cacheKey);
if (cached != null)
return GatewayResponse.FromCache(cached, GetCacheHeaders(request.Path));
}
var service = _registry.ResolveService(request.Path);
if (service == null)
return GatewayResponse.NotFound("Service not found.");
var instance = await service.GetHealthyInstanceAsync();
if (instance == null)
return GatewayResponse.ServiceUnavailable("Service temporarily unavailable.");
var contextHeaders = new Dictionary<string, string>
{
["X-Request-Id"] = Guid.NewGuid().ToString(),
["X-User-Id"] = authResult.UserId ?? "anonymous",
["X-User-Tier"] = authResult.MembershipTier ?? "standard",
["X-Forwarded-For"] = request.ClientIp
};
var response = await ForwardRequestAsync(instance, request, contextHeaders);
if (response.StatusCode == 200 && IsCacheableRoute(request.Path))
{
var cacheKey = $"cache:{request.Path}:{request.QueryString}";
await _cache.SetAsync(cacheKey, response.Body,
TimeSpan.FromSeconds(GetCacheTtl(request.Path)));
}
return response;
}
}Circuit Breaker and Service Mesh
Amazon uses a circuit breaker pattern across all service-to-service calls to prevent cascade failures. Each downstream service dependency has a circuit breaker that tracks failure rates over a sliding window. When the failure rate exceeds a configurable threshold (typically 50% over 30 seconds), the circuit breaker opens and subsequent calls fail fast with a meaningful error message instead of waiting for timeouts. After a configurable recovery period, the circuit breaker enters a half-open state and allows a single probe request through. If the probe succeeds, the circuit breaker closes; if it fails, it reopens. This pattern prevents a failing service from consuming all available threads and connections in the calling service, which is especially critical during Prime Day when a single service degradation could otherwise cascade to the entire platform.
The service mesh layer (built on AWS App Mesh with Envoy sidecars) provides additional resilience features: automatic retries with exponential backoff for transient failures, timeout configuration per service dependency (product service: 50ms, search service: 200ms, payment service: 5s), load balancing across service instances using least-connections algorithm, and mutual TLS (mTLS) encryption for all service-to-service traffic. The service mesh also provides rich observability: per-route metrics, distributed tracing propagation, and access logging without requiring application code changes. During Prime Day, the service mesh team monitors the global circuit breaker state dashboard and can manually trip circuit breakers on non-essential service dependencies to protect the core checkout path.
Rate Limiting Strategy
| Endpoint Group | Per-User Limit | Per-IP Limit | Global Limit | Burst Capacity |
|---|---|---|---|---|
| Product pages | 1,000/min | 10,000/min | 500K QPS | 5,000/sec |
| Search | 500/min | 5,000/min | 100K QPS | 2,000/sec |
| Cart operations | 200/min | 1,000/min | 50K QPS | 1,000/sec |
| Checkout and Payment | 30/min | 100/min | 5K QPS | 200/sec |
| Recommendations | 300/min | 3,000/min | 200K QPS | 3,000/sec |
| Auth (login) | 10/min | 30/min | 10K QPS | 50/sec |
14. Caching Strategy at Every Layer
Caching is the single most impactful performance optimization in Amazon's architecture. With a 100:1 read-to-write ratio, caching at every layer reduces backend load by 90%+ and enables sub-100ms page loads for the majority of requests. Amazon employs a four-layer caching strategy: CDN edge caching (CloudFront, 200+ PoPs worldwide for static assets and cached pages), application-level caching (ElastiCache Redis for hot data like cart contents, sessions, and search results), database-level caching (DynamoDB Accelerator DAX for microsecond-latency DynamoDB reads), and client-side caching (HTTP cache headers, service workers on mobile, and browser local storage for recently viewed products).
C#
public class CacheManager
{
private readonly IDistributedCache _redisCache;
private readonly IAmazonDynamoDBAccelerator _dax;
private readonly ICDNClient _cdn;
public async Task<T> GetWithCacheAsync<T>(CacheKey key, Func<Task<T>> factory,
CacheOptions options = null)
{
options ??= CacheOptions.Default;
if (_memoryCache.TryGetValue<T>(key.FullKey, out var memoryResult))
return memoryResult;
var redisResult = await _redisCache.GetStringAsync(key.FullKey);
if (redisResult != null)
{
var deserialized = JsonSerializer.Deserialize<T>(redisResult);
_memoryCache.Set(key.FullKey, deserialized, TimeSpan.FromSeconds(10));
return deserialized;
}
if (key.Source == CacheSource.DynamoDB)
{
var daxResult = await _dax.GetItemAsync<T>(key);
if (daxResult != null)
{
await CacheInRedisAsync(key, daxResult, options);
return daxResult;
}
}
var result = await factory();
if (result != null)
{
await CacheInRedisAsync(key, result, options);
_memoryCache.Set(key.FullKey, result, TimeSpan.FromSeconds(10));
}
return result;
}
public async Task InvalidateProductCacheAsync(string productId)
{
var patterns = new[]
{
$"product:meta:{productId}",
$"product:desc:{productId}",
$"product:image:{productId}",
$"rec:also_bought:{productId}",
"search:*"
};
foreach (var pattern in patterns)
{
if (pattern.Contains("*"))
{
var keys = await _redisCache.KeysAsync(pattern);
await _redisCache.KeyDeleteAsync(keys);
}
else
{
await _redisCache.RemoveAsync(pattern);
}
}
await _cdn.InvalidateAsync($"/product/{productId}*");
}
}| Cache Layer | Technology | Latency | TTL Strategy | What is Cached |
|---|---|---|---|---|
| CDN Edge | CloudFront | 5-20ms | Static: 24hr, API: 60s | Images, CSS/JS, product pages |
| Application L1 | In-memory | Under 1ms | 10 seconds | Hot products, config, feature flags |
| Application L2 | ElastiCache Redis | 1-3ms | 60s-7 days | Carts, sessions, search results |
| Database | DynamoDB DAX | 0.1-1ms | Matches DB TTL | Frequently read DynamoDB items |
| Client | Browser/App cache | 0ms | HTTP cache headers | Static assets, recently viewed |
15. Monitoring, Observability, and Chaos Engineering
Amazon's monitoring infrastructure observes billions of data points per minute across hundreds of microservices. The observability stack is built on three pillars: metrics (CloudWatch plus custom time-series DB for latency, error rates, throughput, saturation), distributed tracing (X-Ray for end-to-end request tracing across service boundaries), and logging (centralized logging with CloudWatch Logs Insights for structured log analysis). Every service emits standardized SLI/SLO metrics that are aggregated into dashboards and alerting rules. On-call engineers receive PagerDuty alerts when SLOs are at risk, with automated runbooks that attempt remediation before human intervention.
C#
public class ObservabilityMiddleware
{
private readonly RequestDelegate _next;
private readonly IMetricsCollector _metrics;
private readonly ITracer _tracer;
private readonly ILogger<ObservabilityMiddleware> _logger;
public async Task InvokeAsync(HttpContext context)
{
var stopwatch = Stopwatch.StartNew();
var traceId = context.Request.Headers["X-Request-Id"].FirstOrDefault()
?? Guid.NewGuid().ToString();
using var span = _tracer.StartSpan($"{context.Request.Method} {context.Request.Path}")
.WithTag("http.method", context.Request.Method)
.WithTag("http.path", context.Request.Path)
.WithTag("trace.id", traceId);
try
{
await _next(context);
stopwatch.Stop();
_metrics.RecordHistogram("http_request_duration_ms", stopwatch.ElapsedMilliseconds,
new Dictionary<string, string>
{
["method"] = context.Request.Method,
["path"] = NormalizePath(context.Request.Path),
["status"] = context.Response.StatusCode.ToString(),
["service"] = GetServiceName()
});
_metrics.IncrementCounter("http_requests_total",
new Dictionary<string, string>
{
["method"] = context.Request.Method,
["status_code"] = (context.Response.StatusCode / 100).ToString() + "xx"
});
if (stopwatch.ElapsedMilliseconds > GetSloTarget(context.Request.Path))
{
_metrics.IncrementCounter("slo_violations_total",
new Dictionary<string, string>
{
["service"] = GetServiceName(),
["slo_type"] = "latency"
});
}
_logger.LogInformation(
"Request completed: {Method} {Path} {StatusCode} in {Duration}ms [TraceId: {TraceId}]",
context.Request.Method, context.Request.Path,
context.Response.StatusCode, stopwatch.ElapsedMilliseconds, traceId);
}
catch (Exception ex)
{
stopwatch.Stop();
_metrics.IncrementCounter("http_errors_total",
new Dictionary<string, string>
{
["service"] = GetServiceName(),
["error_type"] = ex.GetType().Name
});
throw;
}
}
}
public class ChaosEngineeringService
{
public async Task SimulateFCOutageAsync(string fcId, TimeSpan duration)
{
await _featureFlags.DisableAsync($"fc:{fcId}:available");
await Task.Delay(duration);
await _featureFlags.EnableAsync($"fc:{fcId}:available");
}
public async Task SimulateInventoryDegradationAsync(int delayMs)
{
await _chaosProxy.InjectLatencyAsync("inventory-service", delayMs);
}
public async Task SimulatePaymentFailureAsync(double failRate)
{
await _chaosProxy.InjectErrorRateAsync("payment-gateway", failRate);
}
}Key SLIs and SLOs
| Service | SLI (Indicator) | SLO (Target) | Error Budget (Monthly) |
|---|---|---|---|
| Product Page | p99 latency | Under 100ms | 4.3 min downtime |
| Search | p99 latency | Under 200ms | 4.3 min downtime |
| Cart Service | Write success rate | 99.99% | 4.3 min downtime |
| Order Service | Order success rate | 99.99% | 4.3 min downtime |
| Payment Service | Transaction success rate | 99.999% | 26 seconds downtime |
| Inventory Service | Reservation success rate | 99.99% | 4.3 min downtime |
| Fulfillment Pipeline | Order processing rate | 99.95% | 21.6 min downtime |
16. Prime Day: Peak Traffic Architecture
Prime Day is Amazon's ultimate stress test, generating 12 billion dollars plus in sales over 48 hours with 10x normal traffic. The architecture must handle millions of concurrent shoppers competing for limited-stock deals while maintaining the same reliability and latency as a normal day. Preparation begins 6 months in advance with capacity planning, load testing, chaos engineering drills, and code freezes. Two weeks before Prime Day, infrastructure is pre-scaled to handle projected peak loads. During the event, a dedicated War Room team monitors real-time dashboards and makes live decisions about feature degradation.
Prime Day Traffic Patterns
C#
public class CellBasedRouter
{
private readonly List<Cell> _cells;
private readonly IHealthChecker _healthChecker;
public Cell RouteRequest(string customerId, string requestPath)
{
var hash = ComputeConsistentHash(customerId, _cells.Count);
var cell = _cells[hash];
if (cell.IsHealthy)
return cell;
return _cells.Where(c => c != cell && c.IsHealthy && c.HasCapacity)
.OrderBy(c => c.CurrentLoad)
.FirstOrDefault() ?? cell;
}
}
public class Cell
{
public string CellId { get; set; }
public Dictionary<string, ServiceInstance> Services { get; set; }
public bool IsHealthy => _healthChecker.IsHealthy(CellId);
public double CurrentLoad => GetAggregateLoad();
public async Task<Response> HandleRequestAsync(Request request)
{
if (IsCriticalPath(request.Path))
return await ForwardToServiceAsync(request);
if (CurrentLoad > 0.85)
{
if (request.Path.Contains("/reviews"))
return Response.FromCache("reviews", TimeSpan.FromMinutes(30));
if (request.Path.Contains("/recommendations"))
return Response.FromCache("recs", TimeSpan.FromMinutes(15));
if (request.Path.Contains("/qa"))
return Response.FromCache("qa", TimeSpan.FromHours(1));
}
return await ForwardToServiceAsync(request);
}
private bool IsCriticalPath(string path) =>
path.StartsWith("/api/v1/cart") ||
path.StartsWith("/api/v1/orders") ||
path.StartsWith("/api/v1/payments") ||
path.StartsWith("/api/v1/checkout");
}
public class PrimeDayPreparation
{
public async Task ExecutePreparationsAsync()
{
await ReviewHistoricalDataAsync();
await EstimatePeakTrafficAsync();
await PlanInfrastructureScalingAsync();
await RunLoadTestAsync(targetQps: 15_000_000, duration: TimeSpan.FromHours(4));
await IdentifyBottlenecksAsync();
await SimulateFCOutageAsync(count: 3);
await SimulateDBFailoverAsync();
await SimulateCacheEvictionAsync();
await FreezeNonCriticalDeploymentsAsync();
await PreScaleInfrastructureAsync(multiplier: 10);
await WarmCachesAsync();
await RunFullRehearsalAsync();
await VerifyAlertingPipelinesAsync();
await BriefOnCallTeamsAsync();
}
}Prime Day Degradation Strategy
| Service Tier | Services | Degradation Under Load | Recovery Trigger |
|---|---|---|---|
| Tier 1 (Never Degrade) | Cart, Checkout, Payment, Inventory | None, auto-scaled to handle 10x | N/A |
| Tier 2 (Cache Fallback) | Product Pages, Search | Serve cached results (60s stale) | Load drops below 70% |
| Tier 3 (Delayed Processing) | Order Fulfillment Pipeline | Accept orders, process asynchronously | Queue depth under 100K |
| Tier 4 (Graceful Disable) | Reviews, Q&A, Recommendations | Show cached/generic content | Load drops below 50% |
| Tier 5 (Full Disable) | Product Comparison, Wish Lists | Return 503 with retry-after header | Load drops below 30% |
17. Security, Privacy, and Compliance
Amazon's security architecture protects 300 million plus customer accounts, billions of payment transactions, and terabytes of personal data. The security model follows a zero-trust architecture where every service-to-service call is authenticated and authorized, every data access is logged, and every administrative action requires multi-factor authentication. PCI DSS Level 1 compliance governs all payment data handling: card numbers are tokenized at the API Gateway and never stored in application databases. GDPR and CCPA compliance requires data retention policies, right-to-deletion workflows, and consent management for all customer data processing.
C#
public class SecurityMiddleware
{
public async Task InvokeAsync(HttpContext context)
{
if (IsStateChangingRequest(context.Request))
{
var csrfToken = context.Request.Headers["X-CSRF-Token"].FirstOrDefault();
var sessionToken = context.Request.Cookies["csrf"]?.Value;
if (csrfToken != sessionToken)
throw new SecurityException("CSRF token mismatch");
}
context.Request = SanitizeRequest(context.Request);
context.Response.Headers["Content-Security-Policy"] =
"default-src 'self'; script-src 'self' 'nonce-" + GenerateNonce() + "'";
context.Response.Headers["X-Content-Type-Options"] = "nosniff";
context.Response.Headers["X-Frame-Options"] = "DENY";
context.Response.Headers["Strict-Transport-Security"] =
"max-age=31536000; includeSubDomains; preload";
using (SuppressSensitiveDataLogging(context))
{
await _next(context);
}
}
}
public class EncryptionService
{
public byte[] EncryptAtRest(byte[] plaintext, byte[] key)
{
using var aes = Aes.Create();
aes.Key = key;
aes.Mode = CipherMode.CBC;
aes.Padding = PaddingMode.PKCS7;
aes.GenerateIV();
using var encryptor = aes.CreateEncryptor();
var ciphertext = encryptor.TransformFinalBlock(plaintext, 0, plaintext.Length);
var result = new byte[aes.IV.Length + ciphertext.Length];
Buffer.BlockCopy(aes.IV, 0, result, 0, aes.IV.Length);
Buffer.BlockCopy(ciphertext, 0, result, aes.IV.Length, ciphertext.Length);
return result;
}
public string TokenizeCard(string cardNumber)
{
var vault = new SecureCardVault();
var token = Guid.NewGuid().ToString("N");
vault.StoreMapping(token, cardNumber);
return token;
}
}Security Monitoring and Incident Response
Amazon operates a 24/7 Security Operations Center (SOC) that monitors billions of security events daily using a SIEM (Security Information and Event Management) platform built on Amazon OpenSearch. The SOC team uses machine learning models to detect anomalous access patterns, unauthorized data exfiltration attempts, and credential compromise indicators. Every API call across all microservices is logged to a centralized logging pipeline with structured metadata (user ID, IP address, device fingerprint, request timestamp, response code). The logging pipeline processes over 10 petabytes of security-relevant data daily and retains logs for 90 days in hot storage and 7 years in cold storage for compliance audits.
Incident response follows a standardized runbook framework. When a security alert fires, the SOC analyst follows a pre-defined playbook that includes immediate containment steps (block IP, revoke tokens, isolate affected instances), investigation steps (query logs, trace request paths, analyze payload), and remediation steps (patch vulnerability, rotate secrets, notify affected customers). The mean time to detect (MTTD) target is under 5 minutes for critical security events, and the mean time to respond (MTTR) target is under 30 minutes for confirmed security incidents. Post-incident reviews are mandatory for every P0 and P1 security event, with findings feeding back into preventive controls and detection rules.
Compliance Requirements
| Regulation | Scope | Key Requirements | Audit Frequency |
|---|---|---|---|
| PCI DSS Level 1 | Payment processing | Tokenization, encryption, network segmentation | Annual + quarterly ASV scans |
| GDPR | EU customer data | Right to deletion, consent management, data portability | Annual + incident-based |
| CCPA | California residents | Do Not Sell, data access requests, deletion rights | Annual + incident-based |
| SOC 2 Type II | All customer data | Access controls, monitoring, incident response | Annual |
| ISO 27001 | Information security | ISMS, risk management, security controls | Annual recertification |
| HIPAA | Health data (Amazon Pharmacy) | BAA, minimum necessary, audit logs, encryption | Annual |
18. Interview Questions and Answers
The following questions are commonly asked during system design interviews at Amazon, Google, Meta, and Microsoft. Each question targets a specific architectural decision or tradeoff that senior engineers must understand deeply.
Q1: How would you design Amazon's product catalog to handle 2 billion products?
Use DynamoDB with a single-table design pattern. Partition products by product ID with sort keys for different data types (META, DESC, IMAGE, VARIANT). Base product info is read on every page view and cached in Redis with 5-minute TTL. Descriptions and images are loaded lazily. The search index uses Elasticsearch with 50+ shards, rebuilt daily from a DynamoDB snapshot with incremental updates via Kafka. DynamoDB Global Tables replicate across 3 regions for low-latency reads worldwide. DAX provides microsecond-latency reads for hot products.
Q2: How does Amazon prevent overselling during flash sales?
Two-phase reservation with optimistic locking in DynamoDB. Phase 1 (Reserve): A conditional DynamoDB update atomically decrements available_quantity and increments reserved_quantity if version number matches and stock is sufficient. The reservation has a 15-minute TTL. Phase 2 (Commit): After payment succeeds, the reserved_quantity is decremented permanently. If payment fails or TTL expires, the reservation rolls back. Concurrent checkouts are handled by optimistic lock retries (up to 3 attempts). The version counter prevents write-write conflicts.
Q3: Design Amazon's shopping cart to persist across devices.
Guest carts are stored in Redis with session_id as key (7-day TTL). User carts are stored in Redis with user_id as key (no expiry) with DynamoDB as source of truth (async backup every 30 minutes). When a guest logs in, cart merge runs: guest cart items not already in the user cart are added; existing items are not overwritten. Cart operations publish events to Kafka for analytics. Real-time inventory status is fetched from the Inventory service on every cart display. Price-at-add and current-price are both stored to handle price fluctuations.
Q4: How does Amazon's recommendation engine work?
Multi-algorithm ensemble: (1) Item-to-item collaborative filtering pre-computed on Spark from 90-day order logs (daily batch), finding top-50 similar products per item. (2) Frequently bought together using association rule mining. (3) Content-based using NLP on product descriptions (weekly). (4) Real-time personalized recommendations using browsing history and purchase history via a learning-to-rank model. (5) Trending products based on real-time sales velocity. Results are merged with weights, cached in Redis, and served with sub-50ms latency. The system drives 35% of Amazon's revenue.
Q5: How does Amazon handle Prime Day traffic?
Cell-based architecture isolates customers into independent shards. Pre-scaling begins 2 weeks before Prime Day. Load testing simulates 15M QPS 3 months in advance. Non-critical services degrade gracefully under load. The checkout path is never degraded. Order fulfillment accepts orders synchronously but processes asynchronously with a backlog buffer. Chaos engineering drills simulate FC outages and database failovers. A War Room team monitors dashboards throughout.
Q6: Design Amazon's order management pipeline with exactly-once processing.
Event-sourced saga with idempotency keys. Each step (inventory reservation, payment, confirmation) is independently retryable with compensating actions for failure. Idempotency keys on every external call prevent duplicate processing. Kafka provides at-least-once delivery; idempotent consumers achieve effectively-once semantics. The order state machine is stored in Aurora PostgreSQL with serializable isolation for the critical path. Dead letter queues capture orders that fail after exhausting retries. The entire pipeline is replayable from Kafka events.
Q7: How would you optimize Amazon's search to return results in under 200ms?
Multi-stage pipeline: (1) Query understanding in-memory in the search service. (2) Elasticsearch with optimized index (descriptions excluded from source). (3) Top-500 candidate retrieval with bool query and filters. (4) ML re-ranking only on top candidates. (5) Facet computation with cardinality limits. (6) Results cached in Redis for popular queries (60s TTL). (7) CDN caching for anonymous users. (8) Elasticsearch cluster uses SSD-backed storage with hot/warm architecture. Search index is partitioned into 50+ shards with 2 replicas each.
Q8: Design the payment processing system for Amazon's global marketplace.
Payment service handles authorization, capture, settlement, and refunds. Supports multiple methods: cards, Amazon Pay, gift cards, EMI, UPI. Split payment across methods (gift card balance first, then card for remainder). Fraud detection pipeline analyzes 100+ risk signals in real-time. High-risk transactions require step-up authentication (3D Secure, OTP). Payment tokenization ensures card numbers never touch application servers. Settlement runs as a daily batch job that calculates seller payouts minus Amazon fees. Refunds are processed asynchronously with status tracking. All financial records are stored in Aurora PostgreSQL with ACID guarantees and immutable audit logs.
Q9: How do you handle product search autocomplete with low latency?
Use Elasticsearch completion suggester with a dedicated completion field on each product document. The completion suggester uses a finite state transducer (FST) that is loaded entirely in memory on the Elasticsearch nodes, enabling sub-millisecond lookups. For personalization, maintain a per-user recent searches list in Redis. The autocomplete dropdown shows recent searches first, then completion suggestions, then popular queries. Debounce client-side input by 200ms to reduce backend load. Cache the most popular prefixes in Redis with 5-minute TTL. For very high throughput, deploy a dedicated autocomplete service backed by a pre-computed trie stored in shared memory.
Q10: Design the seller analytics dashboard for 2 million sellers.
Build a separate analytics microservice that consumes order events, inventory events, and review events from Kafka. Store aggregated metrics in a time-series database (Amazon Timestream) partitioned by seller ID and time range. Pre-compute daily, weekly, and monthly aggregates for common dashboard queries. Use materialized views in Aurora PostgreSQL for cross-dimensional analytics (sales by category, region, time). Dashboard API supports 90-day date ranges with p99 latency under 500ms. For real-time metrics, use a streaming aggregation layer (Kafka Streams) that maintains running totals in Redis. Heavy analytics queries (annual reports, cohort analysis) run asynchronously and cache results for 24 hours.