+
+ | Database |
+ Deciding Factors |
+ Decision |
+
+
+ | Product Catalog DB |
+
+
+ - Read-Heavy Data – Product details are read far more often than updated.
+ - Non-Critical Consistency – Slight delays in reflecting updates are acceptable.
+ - High Scalability – Must support millions of concurrent product views.
+
+ |
+ NoSQL (Document) |
+
+
+ | Inventory DB |
+
+
+ - Concurrent Checkouts – Multiple users may attempt to buy the same item.
+ - Strong Consistency – Stale data can cause overselling.
+ - Locking / Versioning – Requires optimistic or pessimistic locking.
+ - Atomic Updates – Quantity updates must be all-or-nothing.
+
+ |
+ Relational (ACID) |
+
+
+ | Cart DB |
+
+
+ - High Read & Write Throughput – Frequent updates during browsing.
+ - Eventual Consistency Acceptable – Cart is revalidated at checkout.
+
+ |
+ NoSQL (Key–Value / Document) |
+
+
+ | Order DB |
+
+
+ - Financial Source of Truth – Represents confirmed purchases.
+ - Atomic Order Creation – Order, payment status, and totals must be consistent.
+
+ |
+ Relational (ACID) |
+
+
+
+### Database Modelling
+#### Product Catalog Schema
+
+
+* Database Type: NoSQL (Document Store)
+* Common Queries:
+ * Fetch product details by `productId`
+ * Fetch products by category or brand
+* Indexing: `productId`, `category`, `brand`
+
+#### Inventory Schema
+
+
+* Database Type: Relational Database
+* Common Queries:
+ * Read available quantity during checkout
+ * Reserve and decrement inventory atomically
+* Indexing: `productId`
+
+#### Cart Schema
+
+* Database Type: NoSQL (Key-Value / Document Store)
+* Common Queries:
+ * Read cart by `cartId`
+ * Add, update, or remove cart items
+* Indexing: `cartId`, `userId`
+
+#### Order Schema
+
+* Database Type: Relational Database
+* Common Queries:
+ * Fetch order details by `orderId`
+ * Fetch all orders of a user by `userId`
+* Indexing: `orderId`, `userId`
+
+### Search Algorithm
+
+Search is the important entry point to sales in an online shopping platform. Most users know the items they like to purchase and search them in the website/app. A fast, accurate search engine can improve the user experience and conversion rates. But building a search system that handles millions of products and returns relevant results in milliseconds is challenging.
+
+Imagine there are 100 million products in the database, and a user searches for "wireless headphones". If we query the database directly using `SELECT * FROM products WHERE name LIKE '%wireless%' OR description LIKE '%headphones%'`, the database would scan every single row, which takes several seconds. The solution is to build a **search index**.
+
+#### Inverted Index
+
+Think of it like an index at the back of a textbook. Instead of reading every page to find mentions of "wireless", we flip to the index, which tells exactly which pages contain that word.
+
+
+
+Search engines like Elasticsearch use an **inverted index** data structure. Instead of mapping **product id to product name**, it maps **word to list of product ids"
+
+
+
+When a user searches for "wireless headphones", the search engine look up both words in the index: `wireless → [prod_001, prod_002]`, and
+`headphones → [prod_001, prod_003]`. The intersection of these lists gives products that contain **both** words. In this case, `prod_001` contains both the words `wireless` and `headphones`.
+
+When a new product is added to the catalog, the search engine processes it through several steps:
+
+1. **Tokenization** - The item name and description are split into a list of words, or tokens. For instance, "Sony Wireless Headphones" turns into [ "Sony", "Wireless", "Headphones"].
+2. **Normalization** - Convert the words to lowercase and remove any special characters. For example, "Headphones" turns into "headphones".
+3. **Stemming** - This step reduces words to their root form. For example, "running" become "run," and "headphones" become "headphone." That way, when a user searches for "headphone," we will also provide the results of "headphones."
+4. **Remove Stop Words** - Remove common words like "the", "a", "and" that don't add search value.
+5. **Indexing** - Add the tokens processed to the inverted index and map every token with the Product ID.
+
+
+### Inventory Consistency
+
+Inventory consistency is one of the critical challenges in e-commerce. Overselling of products (selling more items than available) lead to customer dissatisfaction, order cancellations, and revenue lost. But maintaining consistency when thousands of users are trying to buy the same popular product at the same time is very difficult.
+
+Assume there is only 1 iPhone 15 Pro left in stock. At the exact same time, two customers (Customer A and Customer B) add the iPhone to their cart and proceed to checkout. Lets say both the Customer A and Customer B places the order at the same time. Assume both the orders execute at the same time, both order gets placed but only one customer gets the product delivered and the other customers order get cancelled. This is called a **race condition** - two concurrent transactions read the same data and make decisions based on stale information.
+
+#### Pessimistic Locking
+
+Pessimistic locking prevents race conditions by locking the inventory row during the checkout process. When Customer A starts checkout, the system locks the iPhone 15 Pro inventory row. Customer B's checkout request waits until Customer A's transaction completes.
+
+
+
+**How it works:**
+
+1. Customer A clicks "Place Order".
+2. The Inventory Service acquires a lock on the database row of the iPhone 15 Pro.
+3. The lock prevents any other transaction from reading or modifying that row.
+4. The system checks if inventory is sufficient (1 available), place the order, and decrement the value to 0
+5. The lock is released
+6. Now Customer B's checkout request acquires the lock.
+7. The system checks inventory: 0 available and Customer B receives "Out of Stock" error.
+
+Pessimistic locking `prevent conflicts by blocking`. In a real-world system, when thousands of customers tries to buy the same item at the same time,
+we will block all other orders in favor of one order. This leads to **high latency for customers** and **resource wastage due to waiting transactions**.
+
+#### Optimistic Locking
+
+Optimistic locking assumes conflicts are rare. Instead of locking, the system uses a **version number** to detect conflicts. Since it doesn't have a locking mechanism, it doesn't block other transactions until the first transaction is completed.
+
+
+
+**How it works:**
+
+Each item of the inventory table has a `version` column.
+
+```
+product_id | available_quantity | version
+prod_12345 | 1 | 10
+```
+
+1. Customer A's checkout reads inventory. Available quantity is 1 and the version number is 10.
+2. At the same time, Customer B's checkout reads inventory. Available quantity is 1 and the version number is 10.
+3. Customer A's payment succeeds first. The system tries to update inventory using the below query. The query succeeds because the version is still 10. Version is incremented to 11.
+ ```sql
+ UPDATE inventory SET available_quantity = 0, version = 11 WHERE product_id = 'prod_12345' AND version = 10
+ ```
+4. Customer B's payment succeeds. The system tries to update inventory using the same query. This fails because version is now 11 and there is no entry with version 10. The database returns "0 rows updated".
+ ```sql
+ UPDATE inventory SET available_quantity = 0, version = 11 WHERE product_id = 'prod_12345' AND version = 10
+ ```
+5. The system detects this conflict and retries Customer B's checkout. During retry, we get the available quantity as 0 and the version number as 11
+6. Since there are 0 available quantity, Customer B receives"Out of Stock" error.
+
+Optimistic locking `detect conflicts and retry`. So, unlike pessimistic locking, we don't block all transactions in favor of
+one transaction. When a conflict it detected for other transactions, they retry again to resolve conflicts.
+
+### Recommendation Engine
+
+In online world, recommendation system drives significant amount of sales. The recommendations are shown like **Customers who bought this also bought...**, **Recommended for you**, etc. These suggestions are powered by complex algorithms and machine learning models. We will discuss some of the widely used approaches in recommendation systems.
+
+