System requirements

Functional:

User Management: Registration, login, profile management.

Product Catalog: Browsing, detailed views, search, filtering.

Shopping Cart: Add, update, remove items.

Wishlist: Save products for future consideration.

Order Management: Place orders, view order history, track shipments.

Payment Processing: Secure transactions, multiple payment options.

Seller Portal: Product listing, inventory management, order fulfillment.

Reviews & Ratings: User feedback on products.

Notifications: Order confirmations, promotions, alerts.

Customer Support: Chatbots, ticketing systems.

Non-Functional:

Scalability: Handle peak loads during sales events.

High Availability: Minimal downtime.

Low Latency: Fast response times for user interactions.

Security: Protect user data and transactions.

Data Consistency: Especially for inventory and payments.

Maintainability: Ease of updates and feature additions.

Observability: Monitoring, logging, and alerting mechanisms.

Capacity estimation

Traffic Estimations

• Peak QPS (Queries Per Second): ~20,000 during sales.
• Average QPS: ~5,000.
• Daily Orders: ~2 million.
• Daily Product Views: ~100 million.

Storage Estimations

• Product Catalog: 100 million products × 1KB = ~100GB.
• User Data: 100 million users × 1KB = ~100GB.
• Order Data: 2 million orders/day × 1KB = ~2GB/day.
• Logs & Analytics: ~500GB/day.

API design

USER API

Register a new user: POST /api/v1/users/register

Authenticate user: POST api/v1/users/login

Get user profile: GET /api/v1/users/profile

Logout user: POST /api/v1/users/logout

PRODUCT API

Get product list: GET /api/v1/products

Product detail: GET /api/v1/products/{id}

Add product (admin/seller only): POST /api/v1/products

SEARCH API

Full-text + filtered search: GET api/v1/search/{queryparam}

CART API

Add Item to cart: POST /api/v1/cart/items

Update item in cart: PUT /api/v1/cart/items/{itemid}

Delete item from cart: DELETE /api/v1/cart/items/{itemid}

Get User Cart: GET /api/v1/cart/

ORDER API

Place an Order: POST /api/v1/orders/

Track Order: GET /api/v1/orders/{id}

Order History: GET /api/v1/orders/history

PAYMENT API

Initiate a payment: POST /api/v1/payments/initiate

Verify the transaction: POST /api/v1/payments/verify

REVIEW API

add a review for product: POST /api/v1/products/{id}/reviews

Get all review for a product: GET /api/v1/products/{id}

NOTIFICATION API

Create a new notification (triggered by system events) POST /api/v1/notifications

Fetch all notifications for a user: GET /api/v1/notifications

Fetch only unread notifications: GET /api/v1/notifications?unread=true

Mark a specific notification as read: PUT

/api/v1/notifications/{id}/read

Mark all notifications as read:PUT

/api/v1/notifications/mark-all-read

Delete a specific notification: DELETE

/api/v1/notifications/{id}

Database design

1. Users:
   1. Fields: user_id, name, email, password_hash, created_at, etc.
2. Products:
   1. Fields: product_id, title, description, price, category_id, inventory_count, seller_id, etc.
   2. Index: Full-text index on title and description
3. Categories:
   1. Fields: category_id, name, parent_id (for hierarchy)
4. Carts:Fields: cart_id, user_id, created_at;;Join Table: cart_items: cart_id, product_id, quantity
5. Orders: Fields: order_id, user_id, status, payment_id, total_price, created_at;;Join Table: order_items: order_id, product_id, quantity, price
6. Payments: Fields: payment_id, order_id, amount, status, transaction_id, gateway_response
7. Reviews:Fields: review_id, product_id, user_id, rating, comment, created_at
8. Notifications: Fields: notification_id, user_id, message, type, read, timestamp

1. User Interaction

• Clients (Web or Mobile App) initiate actions (browse, search, add to cart).
• Requests are sent to the API Gateway.

2. API Gateway

• Routes requests to appropriate microservices.
• Handles authentication (JWT tokens), rate limiting, and routing.

3. Product Discovery

• Product Service fetches product data (from Product DB or cache).
• If search is used, it hits the Search Service → powered by Elasticsearch.

4. Cart & Wishlist

• Cart Service stores products in user's cart (in Cart DB, optionally Redis).
• Updates reflect immediately and can be cached for faster retrieval.

5. Order Placement

• User submits order → API Gateway routes to Order Service.
• Order Service:
  • Validates inventory from Inventory Service.
  • Initiates payment via Payment Service.

6. Payment Processing

• Payment Service integrates with external gateways (e.g., Stripe, Razorpay).
• After confirmation (via webhook or verify API), it updates payment status.
• Triggers Order Service to update order status.

7. Notification Trigger

• Notification Service is called (internally via async queue or event).
• Pushes notifications (e.g., "Order confirmed", "Shipped") via:
  • WebSocket (in-app)
  • Email/SMS (via 3rd-party services)

Database Choices

• SQL: PostgreSQL / MySQL
  • For transactional data (orders, payments, carts, users)
• NoSQL: MongoDB / DynamoDB
  • Product catalog (flexible schema), user preferences
• Search: Elasticsearch
  • For full-text search, filtering, faceted queries
• Blob/File Storage: S3/GCS
  • Product images, invoices, digital assets

Partitioning, Replication, Sharding

• Read Replicas: Offload read-heavy endpoints (e.g., product views)
• Horizontal Sharding:
  • User-based sharding for large user base (e.g., user_id % N)
  • Product catalog by category or seller
• Geo-sharding: For global platforms

Storage and Retrieval Strategies

• Indexing:
  • Frequently filtered fields (e.g., category_id, price, created_at)
• Data Compression:
  • On archived data or logs to save cost
• Cold Storage:
  • Archive old orders, notifications after 1 year

Handling Race Conditions & ACID

• Inventory: Use transactions or optimistic locking (e.g., versioning)
• Payments: Ensure idempotency with transaction_id check
• Order Creation: Atomic across cart, order, and inventory tables

Failure Handling

• DB Failover: Promote replica to primary
• Retry Logic: Exponential backoff on transient failures
• Circuit Breakers: Prevent DB overload under pressure

High-level design

Key Components

• API Gateway: Entry point for all client requests.
• Authentication Service: Manages user sessions and security.
• Product Service: Handles product listings and details.
• Search Service: Enables product search and filtering.
• Cart Service: Manages user shopping carts.
• Order Service: Processes orders and payments.
• Inventory Service: Tracks stock levels.
• Payment Service: Integrates with payment gateways.
• Notification Service: Sends emails, SMS, push notifications.
• User Service: Manages user profiles and preferences.
• Review Service: Handles product reviews and ratings.
• Recommendation Service: Suggests products to users.
• Admin Portal: For internal management and analytics.

Data Flow

1. User Interaction: Users interact via web/mobile apps.
2. API Gateway: Routes requests to appropriate services.
3. Services Communication: Services communicate via REST/gRPC or messaging queues.
4. Database Operations: Services perform CRUD operations on their respective databases.
5. Asynchronous Processing: Tasks like sending emails are handled asynchronously.

Technology Choices

• API Gateway: NGINX, Kong, AWS API Gateway.
• Databases:
  • Relational: PostgreSQL/MySQL for transactional data.
  • NoSQL: MongoDB for product catalogs.
  • Search: Elasticsearch for search functionality.
• Caching: Redis or Memcached.
• Messaging: Apache Kafka or RabbitMQ for asynchronous communication.
• Containerization: Docker with Kubernetes for orchestration.
• Monitoring: Prometheus, Grafana, ELK Stack.

Architectural Pattern

• Microservices Architecture: Each service is independent, promoting scalability and maintainability. This approach aligns with industry standards for large-scale e-commerce platforms .

Request flows

1. User Interaction

• User (on web/mobile) selects a product and clicks “Buy Now”.

2. API Gateway

• The request goes to the API Gateway.
• The gateway:
  • Authenticates the user (JWT token)
  • Routes the request to the Cart Service

3. Cart Service

• Validates if product exists and inventory is available (calls Product Service and Inventory logic).
• Adds product to cart or proceeds to order flow.
• Sends request to Order Service.

4. Order Service

• Creates an Order entity with user, product, quantity.
• Locks inventory (calls Product/Inventory Service).
• Calls Payment Service to initiate payment.

5. Payment Service

• Sends request to external Payment Gateway (Stripe/Razorpay).
• After payment:
  • Payment Gateway calls your Webhook/Callback OR
  • Client app calls your /payments/verify API

6. Order Finalization

• Upon successful payment, Order Service:
  • Marks order as PAID
  • Confirms inventory adjustment

7. Notification Trigger

• Notification Service is called (via event/queue or direct).
• Sends real-time update to user via:
  • Push (Firebase/WebSocket)
  • Email/SMS

8. Data Sync

• Order, payment, and notification data are written to their respective databases.
• Optional: Event pushed to Recommendation Service or analytics pipeline.

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

1. Product Service

Responsibilities:

• Serve product listings and detail pages
• Handle search, filters, categories
• Manage stock and metadata (title, price, brand, etc.)

Scalability:

• Read-heavy, so scale horizontally using:
  • Read replicas of DB
  • Caching (Redis) for hot products
  • CDN for product images & static data
• Search/filter via Elasticsearch (inverted index + pagination optimization)

Algorithm/Data Structure:

• Inverted Index: For full-text search
• Trie: For typeahead suggestions in search box
• Bitmap Index: For categorical filtering (e.g., brand=Nike AND size=10)

Reliability:

• Serve stale cache if DB fails
• Auto-retry product fetch from replica DBs if primary is slow

2. Cart Service

Responsibilities:

• Add/update/remove items to/from cart
• Fetch cart state
• Sync cart across devices

Scalability:

• User-specific (session/data isolation) → ideal for horizontal scaling
• Stateless service with user-level partitioning
• Cart stored in Redis (fast read/write, TTL support)
• Fall back to persistent DB on cache miss (e.g., DynamoDB or MongoDB)

Algorithm/Data Structure:

• HashMap (key: product ID, value: quantity) stored per user
• Use LRU or TTL eviction policy in Redis to auto-expire inactive carts

Reliability:

• Retry logic on Redis miss
• Atomic operations using Lua scripts or Redis transactions to avoid race conditions

3. Order Service

Responsibilities:

• Handle order creation
• Validate cart, lock inventory
• Trigger payment, update order status post-payment

Scalability:

• Partition by user_id or order_id
• Write-heavy but order volume can be throttled using queue + async processor
• Use event sourcing to log every order state change

Reliability:

• Idempotency key for order creation to prevent double orders
• Use Saga Pattern to handle distributed transactions (order → payment → inventory)
• Write-ahead logging (WAL) or event log to recover failed transactions

Algorithm/Data Structure:

• Append-only event log for order state transitions
• Bloom filter to prevent duplicate submissions quickly before checking DB

Trade offs/Tech choices

1. Architecture Pattern: Microservices over Monolith

Choice: Microservices Architecture

Why:

• Independent scaling of modules (e.g., cart vs. product)
• Easier team-based development
• Isolated failures (cart service crash doesn’t affect payments)

Trade-offs:

• Increased complexity in deployment and inter-service communication
• Requires API contracts, service discovery, and observability tools
• Needs robust CI/CD and monitoring

Alternative: Monolith for MVP/startups (simpler, faster time-to-market)

2. Protocol: REST vs. gRPC

Choice:

• REST (External APIs) for browser/mobile friendliness
• gRPC (Internal communication) for fast, compact, type-safe inter-service communication

Trade-offs:

• gRPC is less browser-friendly and harder to debug manually
• REST is slower due to JSON overhead and verbose payloads

3. Database Choices: SQL + NoSQL + Search

Choice:

• PostgreSQL (users, orders, payments — relational)
• MongoDB (product catalog — flexible schema)
• Elasticsearch (search, filtering)

Why:

• SQL offers ACID transactions (needed for payments, orders)
• NoSQL supports flexible product data and fast reads
• Elasticsearch provides lightning-fast full-text search and filtering

Trade-offs:

• Managing multiple databases increases ops complexity
• Needs data sync pipelines between product DB → search index
• Join-heavy queries not supported in NoSQL

4. Caching with Redis

Choice: Redis for:

• Product detail caching
• Cart storage (with TTL)
• Session tokens
• Inventory quick reads (hot items)

Why:

• Sub-millisecond reads/writes
• Supports expiration policies and pub/sub

Trade-offs:

• Data persistence not guaranteed (unless using Redis with AOF/RDB)
• Needs cache invalidation logic → cache stampede & staleness risks

5. Asynchronous Messaging with Kafka

Choice:

• Kafka used for:
  • Notification events (order placed → push)
  • Analytics and clickstream
  • Payment/order sync

Why:

• High throughput, reliable delivery
• Decouples producer-consumer logic

Trade-offs:

• Operational complexity
• Requires consumer error handling, replay logic, partition management

Alternative: RabbitMQ for simpler workloads or at smaller scale

6. Authentication: JWT with OAuth

Choice:

• OAuth for third-party integration
• JWT for sessionless, scalable authentication

Why:

• Stateless token validation, works well with load balancing

Trade-offs:

• Token revocation is hard (needs blacklists or short TTL)
• JWT payload bloat with overuse

7. Scalability Choices

Horizontal scaling for:

• Stateless services
• Read replicas for databases
• CDN and cache layers

Why:

• Better cost-efficiency than vertical scaling
• Infinite scaling potential with autoscaling groups

Trade-offs:

• Requires load balancing (L7 for APIs, L4 for DBs)
• Consistency handling across replicas (e.g., eventual consistency in reads)

8. Notification System Design

Choice: Hybrid push-pull model

• Push (WebSocket/Firebase) for real-time alerts
• Pull (API with pagination) for inbox/history

Why:

• Covers both real-time and offline scenarios

Trade-offs:

• Increased development complexity (requires DB + real-time infra)
• Delivery guarantees (e.g., retries, idempotency) need to be built

9. Eventual Consistency vs Strong Consistency

Trade-off:

• Used eventual consistency for:
  • Inventory sync
  • Notifications
  • Search indexing
• Used strong consistency for:
  • Payments
  • Order placement

Why:

• Consistency isn't critical for product views, but essential for transactions

Tech used: Redis for fast cache + PostgreSQL transactions + Kafka for eventual sync

10. Monitoring & Observability

Tools:

• Prometheus + Grafana (metrics)
• ELK Stack (logs)
• OpenTelemetry (tracing)

Why:

• Enables alerting and root cause analysis

Trade-offs:

• Performance overhead
• Setup and tuning complexity

Failure scenarios/bottlenecks

1. API Gateway Failures

Scenarios:

• Gateway crashes or is overloaded
• Malformed requests causing overload
• TLS termination or auth issues

Mitigations:

• Use redundant instances behind a load balancer
• Rate limiting, IP throttling, and WAF (Web Application Firewall)
• Circuit breakers for downstream failures

2. Cart Service Bottlenecks

Scenarios:

• Redis becomes overloaded or evicted keys
• Cart update race conditions (e.g., quantity mismatch)
• Inconsistent state across devices

Mitigations:

• Use TTL + eviction-aware design in Redis
• Redis transactions or Lua scripts to ensure atomicity
• Periodic sync to persistent DB for fallback

3. Order Service Failures

Scenarios:

• Duplicate order submissions
• Order state stuck mid-way due to service crash
• Partial writes (e.g., order saved, inventory not updated)

Mitigations:

• Use idempotency keys on order creation
• Saga pattern to orchestrate multi-step rollback
• Persistent event log for state replay

4. Payment Processing Issues

Scenarios:

• Gateway callback delay or timeout
• Payment confirmed by gateway but missed by system
• Fraud or double payments

Mitigations:

• Verify payment via /verify + signature
• Retry logic for webhook + async polling fallback
• Store transaction_id to avoid duplication

5. Database Bottlenecks

Scenarios:

• Slow queries or unindexed fields
• Write spikes (e.g., flash sale)
• Deadlocks or replication lag

Mitigations:

• Index tuning + query profiling
• Read replicas to offload reads
• Use queue to buffer write spikes (eventual processing)

6. Inventory Inconsistency

Scenarios:

• Two users buying last item at same time
• Stale cache leads to overselling

Mitigations:

• Lock rows or use optimistic concurrency (versioning)
• Place inventory check after payment, not before

7. Search Service Failures

Scenarios:

• Elasticsearch cluster overload
• Delayed product indexing

Mitigations:

• Use bulk index with retry queue
• Implement fallback query on product DB (limited fields)

8. Notification Loss

Scenarios:

• Message lost between service and push/email provider
• Push failed due to device offline

Mitigations:

• Queue + retry delivery attempts
• Store all notifications in DB → fetch on login
• Use dead letter queues for debugging failed messages

9. User Session/Authentication Issues

Scenarios:

• JWT tampering or expiration
• Session hijacking

🛠️ Mitigations:

• Short-lived tokens + refresh tokens
• Blacklisting + IP/device verification
• Secure JWT validation at gateway

10. Rate Limiting and Abuse

Scenarios:

• Bots hitting search/cart/checkout endpoints
• API flooding from malicious actors

Mitigations:

• Token bucket or leaky bucket rate limiting
• CAPTCHA on suspicious traffic
• Use CDN-level and gateway-level rate enforcement

11. Performance Bottlenecks

Scenarios:

• Cold cache after deployment
• High latency in backend service → causes cascading failures

Mitigations:

• Cache warming scripts on deploy
• Timeouts and circuit breakers (e.g., Netflix Hystrix style)
• Use of bulkheads (isolate services to avoid blast radius)

12. Deployment/CI Failures

Scenarios:

• Partial deployment causes service version mismatch
• Env misconfig leads to DB wipe (yes, it happens)

Mitigations:

• Use blue-green or canary deployments
• Automate configuration verification
• Pre-deployment smoke tests + rollback plan

13. Asynchronous Task Failures

Scenarios:

• Kafka consumer crash → unprocessed messages
• Duplicate consumption on retries

Mitigations:

• Idempotent consumers
• Consumer offset tracking and alerting
• Use of retry + dead-letter queues

14. Data Corruption or Loss

Scenarios:

• Manual admin scripts with unintended DELETEs
• Storage corruption (disk/replication bugs)

Mitigations:

• Daily backups + PITR (Point-in-time recovery)
• Audit logs for all admin actions
• Immutable write-ahead logs

Future improvements

1. Auto-Scaling & Service Mesh

Future Enhancement:

• Use Kubernetes Horizontal Pod Autoscaling (HPA)
• Add Service Mesh (e.g., Istio or Linkerd)

Benefits:

• Dynamically scale services during high traffic (e.g., flash sales)
• Fine-grained traffic management, retries, circuit breaking
• Service-to-service encryption and observability

Failure Mitigation:

• Prevent overload at API gateway and service layers
• Isolate failing services with retries and timeouts

2. Asynchronous & Event-Driven Redesign

Future Enhancement:

• Replace some sync operations (e.g., order → payment → inventory) with event-based pipeline using Kafka or NATS
• Ensure all critical operations are idempotent

Benefits:

• Improved decoupling, resilience, and retry handling
• Enables easier recovery after partial failures

Failure Mitigation:

• Prevent cascading failures due to downstream service issues
• Reprocess events from dead-letter queues

3. ML-Based Anomaly Detection

Future Enhancement:

• Use ML models to detect anomalies in:
  • Traffic spikes (potential DDoS)
  • Payment failures
  • Inventory overselling

Benefits:

• Real-time alerting
• Proactive failure identification

Failure Mitigation:

• Early detection of system issues before impact widens

4. Cost Optimization & Tiered Storage

Future Enhancement:

• Use tiered storage (e.g., S3 Glacier for old orders/invoices)
• Archive logs/data not needed in real-time

Benefits:

• Reduce operational costs
• Clean separation between hot and cold data

Failure Mitigation:

• Prevent storage saturation that may affect active systems

5. JWT Revocation & Auth Flow Hardening

Future Enhancement:

• Introduce refresh token rotation and blacklist
• Secure device-based session tracking

Benefits:

• Better session control for security
• Avoid stale token abuse

Failure Mitigation:

• Protect users from token theft and session hijacks

6. Advanced Observability & Alerting

Future Enhancement:

• Use OpenTelemetry to collect traces + metrics + logs in one system
• Implement SLI/SLO/SLAs for core APIs

Benefits:

• Holistic visibility into system behavior
• Quick root cause analysis with trace linking

Failure Mitigation:

• Reduce MTTR (Mean Time To Recovery)
• Catch slow-degrading performance issues early

7. Improved Notification Pipeline

Future Enhancement:

• Store delivery status (sent, failed, read) per channel (email, SMS, push)
• Use retry queues + priority queues for order-related alerts

Benefits:

• User trust increases with confirmed comms
• Reduced message loss during peak

Failure Mitigation:

• Ensure every critical user notification reaches the target

8. Blue-Green or Canary Deployments

Future Enhancement:

• Use Canary or Blue-Green deployments in Kubernetes
• Auto-rollback on failure conditions

Benefits:

• Minimize production bugs
• Seamless releases with zero downtime

Failure Mitigation:

• Prevent broken builds from hitting 100% of users

9. Data Protection and Backup Enhancements

Future Enhancement:

• Encrypt all data at rest (DBs, S3, logs)
• Snapshot-based backups + PITR for all stores

Benefits:

• Ransomware and data loss protection
• Regulatory compliance (GDPR, PCI-DSS)

Failure Mitigation:

• Rapid recovery from logical errors or malicious deletions

10. Real-Time Inventory Lock Service

Future Enhancement:

• Centralized inventory lock manager (Redis-backed) for flash sales
• Use Redis sorted sets or atomic counters

Benefits:

• Prevent overselling
• Fair ordering in high-concurrency scenarios

Failure Mitigation:

• Eliminate race conditions on last-stock items

11. Global Scalability (CDN, Geo-sharding)

Future Enhancement:

• Deploy Geo-sharded databases
• Use CDN caching for static content and APIs

Benefits:

• Faster response for global users
• Lower latency, reduced load on origin servers

Failure Mitigation:

• Improved fault isolation across regions