Design e‐commerce Solution - kdwivedi1985/system-design GitHub Wiki

Design systems like Amazon, Flipkart, Groupon.

Functional Requirements

  • Register User
  • Product and Catalog
  • Product Listing & Search
  • Price and Discount
  • Inventory Updates
  • Notification
  • Real-time Recommendations

Non-Functional Requirements

  • Scalable and High Performance - Session Cache, Edge Cache, Replication(Node, DB-read replicas, sharding)
  • Support Millions of hits/orders - NoSQL DB, Caching and Async processing
  • Operates in multiple regions/ countries- Sharding
  • Resilient- Deploy in multiple reasons and take regular backups.

Complete System Design

Tools & Services

  • Microservices- Build based on microservices architecture
  • Load Balancer- for scalability and Resillience
  • API Gateway- for traffic routing
  • Object/Image Store- S3, AdobeScene7 - For storing media files (images, videos, thumbnails)
  • CDN (Content Delivery Network)- Caching content at edge. (static files and media)
  • Elasticache - for free text search and product listing
  • Redis - Caching cart, inventory, user sessions and frequently used items
  • Meta-Data (MongoDB)- Store reference to media. e.g. product image links with product document
  • Wide column/Key-val (Casandra) - for frequent writes and multi region clusters [Resilience and geo based Sharding]
  • Event Stream (Kafka, RabbitMQ) -[Event Stream for asynchronous processing of orders, click streams etc.]
  • Relation DB (PostgreSQL) - for Regional/geo-based Sharding, high read/writes
  • Event Processing (Flink/Spark Streaming)- for data processing from Kafka. Flink is faster than Spark stream and real-time.
  • Data Lake/Warehouse (Hadoop)- for long-term persistence, ML model training and analytics

image

Why you opted for Mongodb for User, Product & Catalog and Payment Service?

  • Users and their profiles are global can be accessed from anywhere. So we can store user credentials, profile, preferences and ship to addresses in Mongo. Can handle millions of reads.
  • Product & Catalog, along with price and discount for B2C can be stored in Mongo with geo-based sharding.
  • We can product and price in one object and discount in separate as it may change frequently and Cache frequently accessed data in regional redis clusters.
  • For B2B we can have completely separate pricing and discount service with small relational DBs for complex pricing. Payments can also be stored in geo-based shards due to compliance.

Why is Redis cache used for product, Carts and Inventory?

  • Redis is in-memory, fast and support atomic, single threaded transactions. To overcome race condition we can use atomic batch operations or EVAL (lua scripts) to reduce the chances, or use redis distributed locks.
  • Use INCR, DECR, LPOP etc for inventory.
  • Carts are temporary, so can be stored regional redis clusters.
  • Regional redis clusters to store frequently accessed products.

What is Elastic cache used for?

  • Elastic Cache/Solr is to index the products for fast free text search and product listing

Checkout, Inventory Updates and Notification

image Why PostgreSQL is selected for Orders? How will end-to-end ordering work?

  • Postgre supports horizontal sharding. so orders can be geo-based sharding can be implemented for orders.
  • Order may follow strict schema with isolated objects. e.g. order, entry, product etc. line items may require updates for shipping, refund, processing, querying capabilities may be needed for order status,reporting, listing, grouping and relational data is better is such cases. Also, it is ACID complaint and referential integrity is supported OOTB while Mogo 4.2+ supports constraints but not as strict and extensive like SQL. They is less use cases and community support.

Why Cassandra + Redis is selected for inventory, how consistency is ensured for inventory?

  • Cassandra can handle millions of read and write both and inventory may have frequent updates. We can create multi-region clusters with stock, warehouse etc. Cassandra is eventual consistent, so we can use Redis in front- of that for frequently read and locking the inventory. Cassandra can be updated separately through Kafka fleet and requests can be batched. Use UUID/ idempotency for updates. Eventually sync cache- cassandra using jobs. Cache miss can go to Cassandra directy.
  • For flash sale you can store inventory queue and use LPOP for consistency. [1,1,1,1,1,1]

Real-Time recommendations

image

How Real-time recommendations works?

  • Send click stream data to Kafka. For real-time processing use spark streaming or flink. Use Fanout- Insert features in feature-store (Redis, Mongo, Cassandra for fast processing e.g. user, products etc.)
  • Also, store same data in Hadoop for permanent storage for model training and analytics
  • If used clicks on PDP, call recommendation service, which extracts features from feature store, pass that to ML inference to extract recommendations.

References