All you need for System Design Interviews 📌 github.com/liquidslr/system-…

HLD Interview Notes: Day 9/30 Topic: Cache Stampede Prevention: Locks, Request Coalescing and Refresh-Ahead Your cache works perfectly until a popular key expires and thousands of requests hit your database at once. How do you prevent a cache miss from turning into a production incident? 1. Cache Stampede: The Problem A cache stampede happens when many requests try to rebuild the same expired cache entry simultaneously. Example: A shopping website caches popular product details.The cache expires during a big sale.Thousands of requests miss the cache and query the database. Database load spikes, response times increase, and the service may become unavailable. 2. Distributed Locking Allow only one worker to refresh an expired cache entry at a time. First request acquires a lock.It fetches fresh data from the database.It updates the cache and releases the lock.Other requests wait briefly or use a fallback. Best for: Preventing multiple workers from rebuilding the same key. Trade-off: Lock timeouts, failed workers and incorrect lock handling can create problems. 3. Request Coalescing Combine concurrent requests for the same missing key into one database fetch. First request triggers the fetch.Other requests for the same key wait for the result.The fetched value is shared among waiting requests. Best for: Reducing duplicate work for popular keys. Trade-off: Waiting requests may experience additional latency. 4. Refresh-Ahead Refresh frequently accessed cache entries before they expire. Identify popular cache entries.Refresh them in the background before expiration.Keep serving cached data while the refresh happens. Example: A product page refreshes its cached details before a major sale begins. Best for: Predictable, read-heavy workloads. Trade-off: Some refreshed data may never be used, increasing unnecessary database work. 5. Quick Comparison Distributed locking: Controls which worker refreshes a key.Request coalescing: Shares one in-flight fetch among concurrent requests.Refresh-ahead: Refreshes data before it expires. 6. Interview Tip When designing cache stampede protection, ask: Can multiple requests rebuild the same key?Should requests wait, or can they use stale data?What happens if the refresh worker crashes?How do we prevent a lock from becoming a bottleneck? FAANG Takeaway Preventing cache stampedes is about controlling concurrent work, not just increasing cache hit rates. Combine the right strategy with timeouts, TTL jitter and database protection to make caching more resilient under heavy traffic. Next: Day 10/30 Cache Warming and Preloading Strategies

Blind 75: Day 37/75 Problem: Palindromic Substrings LeetCode 647: leetcode.com/problems/palind… Given a string s, return the number of palindromic substrings in it. Every occurrence counts separately, even if the same substring appears at different positions. Example 1 Input: s = "abc"Output: 3Explanation: "a", "b", "c" Example 2 Input: s = "aaa"Output: 6Explanation: "a", "a", "a", "aa", "aa", "aaa" Approach: Expand Around Center Every palindrome has a center, which can be a character or a gap between two characters. Iterate through every possible center.Expand left and right while the characters match.Increment the count for every valid palindrome found.Check both odd-length and even-length centers. Complexity Let (n) be the length of the string. Time: O(n²)Space: O(1) auxiliary space FAANG Takeaway This problem uses the same Expand Around Center technique as Longest Palindromic Substring. The difference: instead of tracking the longest palindrome, count every valid palindrome found during expansion. Next: Day 38/75 Longest Repeating Character Replacement (LC 424)

if the goal is to build an Indian app store, build a brand that can stand on its own slapping PhonePe on everything isn't needed, it's just brand extension

the best use of AI for me isn’t writing code it’s deleting the boring parts so i can focus on the parts that break

Cheating might get you a rank, but it won't get you the skills to back it up! Solving all 4 problems in a LeetCode contest in just 1–4 minutes is wild. Reading, understanding, finding the optimal approach, coding and debugging all in that time? Competitive programming is getting intense. If the results are legitimate, that's an incredible level of problem-solving speed. But suspicious patterns deserve proper scrutiny too. Fair competition matters. Rankings only mean something when everyone plays by the same rules.

Are vibe coders even aware of these 50 things? Database Indexes Race Conditions API Rate Limiting Database Transactions Cache Stampedes Connection Pooling Dead Letter Queues ACID Properties Webhook Verification Distributed Tracing N+1 Queries Circuit Breakers Database Sharding Optimistic Locking Exponential Backoff Zero-Downtime Migrations Message Queues Isolation Levels Idempotency Load Balancing Query Optimization Graceful Shutdown Redis Eviction Policies Foreign Key Constraints Replication Lag Background Workers Deadlocks Eventual Consistency Read Replicas Retry Mechanisms Database Migrations Backpressure Pessimistic Locking Horizontal vs Vertical Scaling Webhook Retries EXPLAIN ANALYZE Distributed Caching Unique Constraints Outbox Pattern Health Checks Database Partitioning Job Scheduling Reverse Proxies Distributed Transactions Cache Invalidation Event-Driven Architecture Jitter CQRS Event Sourcing Circuit Breaker Recovery Strategies Building a working demo is one thing. Building a system that survives real users, failures, traffic spikes, and messy data is a completely different game.

cursor writes the code claude reviews it i still have to fix the edge cases myself

Can a 6-month vibe coder outperform a 3-year developer?

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)