SCR

30-day DSA revision roadmap 📌 5 LeetCode problems a day. 30 days. 150+ problems to revise. Topics covered: Arrays & Hashing Two Pointers & Sliding Window Binary Search & Linked Lists Stacks & Monotonic Stacks Heaps, Intervals & Greedy Trees, BSTs & Graphs Backtracking & Dynamic Programming Tries, Bit Manipulation & Union-Find Advanced Graphs, Strings & Data Structures Follow this approach: Brute Force → Better → Optimal → Pattern → Complexity Don't just memorize solutions. Understand the pattern, revisit your mistakes, and practise explaining your approach. Save this for your next DSA revision.

5 messaging patterns every system design interview candidate should know: 1. Point-to-point One message goes to one worker. 2.Publish/subscribe Subscribers receive messages for the topics they follow. 3. Fan-out One event is copied to multiple queues or consumers. 4. Request-reply A client sends a request and receives a response. 5. Event streaming Events are stored so consumers can process or replay them. Each pattern solves a different communication problem. Know when to use each one for your HLD interviews.

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