LLD Interview Notes: Day 16/50 Topic: Observer Pattern What if one object's state changes and multiple other objects need to be notified automatically? That's exactly what the Observer Pattern solves. 1. What Is the Observer Pattern? A behavioral design pattern where one object, called the Subject, notifies multiple dependent objects, called Observers, whenever its state changes. It creates a one-to-many relationship without tightly coupling the objects. 2. How It Works Subject maintains a list of observers. Observers subscribe to receive updates. When the subject changes, it notifies all subscribed observers. Observers react to the notification independently. 3. Real-World Example: YouTube Notifications Imagine subscribing to a YouTube channel. Channel = Subject Subscribers = Observers New video uploaded = State change Notifications sent to subscribers = Observer updates The channel doesn't need to know how each subscriber handles the notification. 4. UML Structure Subject: attach(), detach(), notify() Observer: update() ConcreteSubject: maintains state and triggers notifications ConcreteObserver: implements update() to react to changes 5. Where Is It Used? Event-driven systems Notification services GUI event listeners Stock price monitoring Publish-subscribe mechanisms 6. Common Interview Mistakes Confusing Observer with Strategy. Forgetting to unsubscribe observers, causing memory leaks. Ignoring notification ordering and error handling. Creating circular notifications or unintended update loops. FAANG Takeaway Observer Pattern answers: How can one object notify multiple dependent objects without tightly coupling them? It makes systems extensible, but you must consider subscription management, delivery guarantees and performance when many observers are involved. Next: Day 17/50 Decorator Pattern in LLD

HLD Interview Notes: Day 8/30 Topic: Cache Consistency: TTL, Invalidation and Write Strategies Your cache makes applications faster. But how do you ensure users don't keep receiving outdated data? Three important concepts every system design interview candidate should understand. 1. Time-To-Live (TTL) Problem: Cached data can become outdated as the source data changes. How it works: Every cache entry gets an expiration time. Once the TTL expires, the entry becomes eligible for removal or refresh. The next request may fetch fresh data from the database. Example: A product listing is cached for 5 minutes. After expiration, the application fetches updated product details. Best for: Data that can tolerate some staleness. Trade-off: A short TTL increases database load. A long TTL increases the chance of serving stale data. 2. Cache Invalidation Problem: Database data changes, but the cache still contains the old value. How it works: Update the database. Invalidate or delete the corresponding cache entry. The next cache miss loads the updated value. Example: When a product's price changes, delete its cached price so the next request retrieves the latest value. Best for: Applications that need fresher data after updates. Trade-off: Incorrect invalidation logic can leave stale entries behind. Concurrent updates can also introduce race conditions. 3. Write Strategies and Consistency Problem: Updating the cache and database independently can cause them to disagree. Common approaches: Write-through: Update the cache and database as part of the same write flow. Write-back: Update the cache first and persist to the database asynchronously. Cache-aside: The application updates the database and invalidates or refreshes the cache. Example: A shopping application updates a product price in the database and invalidates the cached price. Best for: Choosing a consistency model that fits the application's requirements. Trade-off: Stronger coordination can increase latency, while asynchronous writes and invalidation can introduce consistency risks. 4. Quick Comparison TTL: Expire cached entries after a configured duration. Invalidation: Remove or refresh entries when data changes. Write-through: Coordinate cache and database updates. Write-back: Persist cached writes asynchronously. Cache-aside: Let the application manage cache reads and updates. 5. Interview Tip When designing cache consistency, ask: How stale can the data be? What should happen when the database value changes? Can two requests update the same key concurrently? What happens if cache invalidation fails? Is eventual consistency acceptable, or is stronger consistency required? FAANG Takeaway There is no single cache consistency strategy for every workload. Choose based on data freshness, write patterns, latency requirements and failure scenarios. A fast cache is useful only when its consistency guarantees match what the application needs. Next: Day 9/30 Cache Stampede Prevention: Locks, Request Coalescing and Refresh-Ahead

Blind 75: Day 36/75 Problem: Longest Palindromic Substring LeetCode 5: leetcode.com/problems/longes… Given a string s, return the longest substring that reads the same forward and backward. Example 1 Input: s = "babad" Output: "bab" Note: "aba" is also a valid answer. Example 2 Input: s = "cbbd" Output: "bb" Approach: Expand Around Center Every palindrome has a center. It can be a single character (odd length) or the gap between two characters (even length). Iterate through every possible center. Expand left and right while the characters match. Track the longest palindrome found. Return the corresponding substring. Complexity Let (n) be the length of the string. Time: O(n²) Space: O(1) auxiliary space FAANG Takeaway The key insight is that a palindrome can be expanded outward from its center. This approach is simpler and more space-efficient than checking every possible substring. Next: Day 37/75 Palindromic Substrings (LC 647)

10 free resources to learn computer science from the best universities. 📌 CS Video Courses: github.com/Developer-Y/cs-vi… Harvard CS50: cs50.harvard.edu/x/ MIT Missing Semester: missing.csail.mit.edu/ MIT Introduction to Algorithms: ocw.mit.edu/courses/6-006-in… Operating Systems: Three Easy Pieces: pages.cs.wisc.edu/~remzi/OST… Computer Networking by Jim Kurose: youtube.com/@JimKurose CMU Database Systems: 15445.courses.cs.cmu.edu/ Nand2Tetris: nand2tetris.org/ MIT Mathematics for Computer Science: openlearninglibrary.mit.edu/… Neural Networks: Zero to Hero by Andrej Karpathy: karpathy.ai/zero-to-hero.htm… Save this list. Start with one course, finish it, and build projects along the way.

HLD Interview Notes: Day 7/30 Topic: Cache-Aside vs Read-Through vs Write-Through vs Write-Back Where should caching logic live, and when should data be written to the database? These four caching strategies help you balance performance, consistency, and reliability in system design. 1. Cache-Aside (Lazy Loading) Problem: The application manages cache loading itself. How it works: Application checks the cache first. On a cache miss, it fetches data from the database. The application stores the result in the cache. Example: A product page loads product details from the database only when the cache misses. Best for: Read-heavy applications where not every database record needs to be cached. Trade-off: The first request after a cache miss is slower, and stale data can remain unless invalidated. 2. Read-Through Cache Problem: The application shouldn't need to manage cache misses directly. How it works: Application requests data from the cache. On a cache miss, the cache loads data from the database. The cache stores the result and returns it. Example: A user profile service reads through a caching layer that fetches missing profiles automatically. Best for: Applications that want to simplify read logic. Trade-off: Requires a cache layer that supports loading data from the backing store. 3. Write-Through Cache Problem: The cache and database should be updated together on writes. How it works: Application writes data to the cache. The cache writes the data to the database. The write is acknowledged after both writes succeed. Example: Updating a product's price through a write-through caching layer. Best for: Workloads that prioritize keeping cached data consistent with the database. Trade-off: Writes can have higher latency because the database must also be updated. 4. Write-Back (Write-Behind) Cache Problem: Database writes can become a performance bottleneck. How it works: Application writes data to the cache. The cache acknowledges the write. The database is updated asynchronously, often in batches. Example: Recording frequent counters or analytics events before flushing updates to persistent storage. Best for: Write-heavy workloads where lower write latency is important. Trade-off: A cache failure before data is persisted can cause data loss unless durable logging or replication protects pending writes. 5. Quick Comparison Cache-Aside: Application handles cache misses and cache updates. Read-Through: Cache handles loading missing data. Write-Through: Cache and database are updated synchronously. Write-Back: Cache accepts writes first; database updates happen later. 6. Interview Tip When choosing a caching strategy, ask: Is the workload read-heavy or write-heavy? How fresh must the data be? Can the application tolerate stale data? What happens if the cache fails before a write reaches the database? FAANG Takeaway There is no universally best caching strategy. The right choice depends on read/write patterns, consistency requirements, latency goals, and failure handling. Next: Day 8/30 Cache Consistency: TTL, Invalidation and Write Strategies

Blind 75: Day 34/75 Problem: Implement Trie (Prefix Tree) LeetCode 208: leetcode.com/problems/implem… Design a Trie data structure that supports inserting words, searching for complete words, and checking whether any word starts with a given prefix. Example 1 Operations: insert("apple") search("apple") → true search("app") → false startsWith("app") → true insert("app") search("app") → true Approach: Trie + Character Nodes Each node represents a character and stores links to its children. Insert: Traverse the word character by character, creating missing nodes. Search: Follow the character links and check whether the final node marks the end of a word. Prefix Search: Follow the links and return true if the entire prefix exists, even if it isn't a complete word. Complexity Let L be the length of the word or prefix. Insert: O(L) Search: O(L) Prefix Search: O(L) FAANG Takeaway A Trie makes prefix-based operations efficient by sharing common prefixes between words. It's useful for autocomplete, dictionaries, and prefix matching. Next: Day 35/75 Add and Search Word: Data Structure Design (LC 211)

HLD Interview Notes: Day 6/30 Topic: Cache Stampede, Cache Penetration and Cache Avalanche Your cache is supposed to protect the database. But what happens when caching itself creates a traffic problem? Three common failure scenarios every system design interview candidate should understand. 1. Cache Stampede Problem: A popular cache key expires, and thousands of requests try to fetch the same data from the database simultaneously. Example: A product page's cache expires during a sale. Every incoming request hits the database. Solutions: Request coalescing: Let one request fetch the data while others wait. Distributed locking: Allow one worker to refresh the cache. Background refresh: Update popular entries before they expire. 2. Cache Penetration Problem: Requests repeatedly ask for data that doesn't exist in the database, causing cache misses every time. Example: Bots request thousands of nonexistent product IDs. Every request reaches the database. Solutions: Cache negative results for a short TTL. Use a Bloom Filter to identify keys that definitely don't exist. Validate requests before querying the database. 3. Cache Avalanche Problem: Many cache entries expire simultaneously, causing a sudden surge of requests to the database. Example: Thousands of product entries share the same TTL and expire together. Solutions: Add random jitter to TTLs. Use staggered expiration times. Apply rate limiting and load shedding to protect the database. 4. Quick Comparison Stampede: Many requests for the same expired key. Penetration: Requests for nonexistent data. Avalanche: Many keys expire around the same time. 5. Interview Tip When diagnosing a cache problem, ask: Is one hot key causing too many requests? Are requests targeting data that doesn't exist? Are many keys expiring together? The answer helps you choose the right mitigation. FAANG Takeaway Caching is not just about hit rates. It's also about protecting the database when the cache fails to serve a request. Design for cache misses, expiration spikes, and malicious traffic before they become production incidents. Next: Day 7/30 Cache-Aside vs Read-Through vs Write-Through vs Write-Back

5 sorting algorithms every developer should know. Bubble Sort: Swap adjacent elements until sorted. Selection Sort: Find the smallest element and move it to the front. Insertion Sort: Insert each element into its correct position. Merge Sort: Divide the array, sort each half, then merge. Quick Sort: Pick a pivot and partition around it. Don't just memorize the names. Understand how each algorithm works, when to use it, and its time complexity. Save this for your DSA revision.

this is the kind of stuff we need more!!! >billionaires investing in new industries >big companies building things beyond their usual businesses >more investment in aerospace, defence, semiconductors, robotics and AI >more factories, more R&D, more skilled jobs >more opportunities for freshers to explore different fields >less dependence on importing everything from other countries >more indian companies building products the world actually uses imagine how many jobs and new career paths this could create for young people. we need more companies taking risks, building new things and creating industries instead of everyone fighting for the same limited opportunities more innovation means more industries, more jobs and more hope for the next generation

LLD Interview Notes: Day 15/50 Topic: Strategy Pattern vs State Pattern Both patterns use composition and polymorphism, but they solve different problems. 1. Strategy Pattern Use it when you want to switch between different ways of performing the same task. Example: Payment processing UPIPayment CardPayment PayPalPayment All implement a common PaymentStrategy interface. The checkout service uses the selected strategy without needing to know its internal implementation. 2. State Pattern Use it when an object's behavior changes depending on its current state. Example: Order management Pending → Confirmed → Shipped → Delivered Each state defines what actions are allowed and how the order behaves. 3. Key Differences Strategy Pattern Chooses an algorithm or behavior. Usually selected by the client or application. Makes implementations interchangeable. State Pattern Represents an object's current state. Behavior changes as the object transitions between states. Helps manage state-dependent rules and transitions. 4. Quick Example Imagine an e-commerce application. Payment method changes from UPI to card: Strategy Pattern Order changes from Pending to Shipped: State Pattern 5. Common Interview Mistakes Treating both patterns as interchangeable. Using inheritance when composition is sufficient. Adding patterns when a simple method or conditional is enough. Forgetting to explain the problem the pattern solves. FAANG Takeaway Strategy answers: Which behavior or algorithm should I use? State answers: How should I behave in my current state? Both improve flexibility, but the choice depends on what is changing in your system. Next: Day 16/50 Observer Pattern in LLD