Venkatesh

Someone found our public signup endpoint and scripted it. No rate limit. No CAPTCHA. No email verification gate. 40,000 fake accounts in six hours. Support thought it was a viral moment. It was a bot with a for loop. How do you rate-limit signup without punishing real users?

🚨11 Database concepts every backend developer should understand: 𝟏. 𝐂𝐀𝐏 𝐓𝐡𝐞𝐨𝐫𝐞𝐦: Distributed Databases 𝟐. 𝐄𝐯𝐞𝐧𝐭𝐮𝐚𝐥 𝐂𝐨𝐧𝐬𝐢𝐬𝐭𝐞𝐧𝐜𝐲: Distributed Systems 𝟑. 𝐈𝐬𝐨𝐥𝐚𝐭𝐢𝐨𝐧 𝐋𝐞𝐯𝐞𝐥𝐬: Concurrent Transactions 𝟒. 𝐑𝐞𝐩𝐥𝐢𝐜𝐚𝐭𝐢𝐨𝐧: Read Scaling 𝟓. 𝐈𝐧𝐝𝐞𝐱𝐢𝐧𝐠: Faster Queries 𝟔. 𝐃𝐞𝐚𝐝𝐥𝐨𝐜𝐤𝐬: Concurrent Access 𝟕. 𝐒𝐡𝐚𝐫𝐝𝐢𝐧𝐠: Write & Data Scaling 𝟖. 𝐏𝐚𝐫𝐭𝐢𝐭𝐢𝐨𝐧𝐢𝐧𝐠: Large Tables 𝟗. 𝐐𝐮𝐞𝐫𝐲 𝐏𝐥𝐚𝐧𝐬: Performance Analysis 𝟏𝟎. 𝐂𝐨𝐧𝐧𝐞𝐜𝐭𝐢𝐨𝐧 𝐏𝐨𝐨𝐥𝐢𝐧𝐠: Efficient Connections 𝟏𝟏. 𝐓𝐫𝐚𝐧𝐬𝐚𝐜𝐭𝐢𝐨𝐧𝐬: Data Consistency

You don't become a senior developer by surviving more years. You become one by solving bigger problems. Focus on learning: 1. Production debugging 2. System design 3. Architecture trade-offs 4. Database internals 5. Caching strategies 6. Observability 7. Security fundamentals 8. Cost optimization 9. Technical communication 10. Decision making under uncertainty Coding is only one part of engineering.

Systems Design Interview: One slow downstream dependency. No circuit breaker anywhere in the call path. Every request grabs a thread and waits on it. Thread pool has a limit. Limit gets hit. Now requests that never touch that dependency can't get a thread either. How do you stop one slow service from taking the whole app down?

Copied the same user object two different ways in one PR. Edited the copy, not the original, on both sides. Only one original stayed untouched. QA found the other one three days later.

Interviewer: "Walk me through how you'd design a URL shortener." Candidate: starts drawing boxes immediately. That's the moment most system design interviews are already lost. What separates a pass from a reject in the first 60 seconds: 1, They ask about scale before drawing anything 2, They clarify read vs write ratio out loud 3, They estimate storage before picking a database 4, They say "I'll start simple and add complexity" instead of over-engineering from line one 5, They ask about consistency requirements before naming a specific database 6, They think about failure before thinking about features 7, They say "here's what I'd cut if we had less time" unprompted I've sat on both sides of this table. The candidates who get offers aren't smarter. They just don't start drawing boxes first. What's the first question you ask in a system design interview?

Here's the question that stumped me in an interview: You request an Uber right as you walk into a subway tunnel and lose signal completely. Thirty seconds later, back above ground, a driver is already five minutes away. How?

This is actually a pretty interesting problem with browser agents. Why should an AI agent rediscover the same website and repeat the same work every single time? If it can remember the route and reuse it, browser automation becomes way more efficient. Definitely worth checking out 👀

A developer showed me a system design. Everything looked perfect. Load balancer. Multiple servers. Redis. Kafka. Database replicas. Multi-region deployment. I asked one question: “What happens when the network between two regions breaks?” He paused. So I continued. Users in India are writing to Region A. Users in the US are writing to Region B. Both regions are healthy. Both databases are healthy. But they can't communicate. Now two users update the same account. At almost the exact same time. Region A says: Balance = ₹500 Region B says: Balance = ₹700 The network comes back. Now what? Which value wins? How do you merge the changes? Do you prefer: → Strong consistency? → Eventual consistency? → Last-write-wins? → Conflict resolution? → Single-writer architecture? And suddenly… the hardest part of the system isn't the database. It's deciding what “correct” actually means. This is why distributed systems are hard. The machines aren't the scary part. The failures between them are. What would you choose?

Video streaming engineers live and die by this distinction: - TCP - UDP Do you care more about every packet arriving, or arriving fast?

If I had to become a better software engineer this year, I'd stop chasing every new framework. I'd focus on fundamentals that survive frameworks. MONTH 1 — Code Master: • One programming language • Data structures • Algorithms • OOP • Error handling • Testing • Debugging Build: → Something people can actually use Goal: Write code you can understand 6 months later. MONTH 2 — Databases Learn: • SQL • Indexes • Transactions • Constraints • Replication • Caching • Data modeling Build: → Application with a real database Then inspect your slow queries. MONTH 3 — Backend Understand: • HTTP • REST • Authentication • Authorization • Sessions • APIs • Background jobs • Queues Build: → Production-style backend Don't just make endpoints work. Think about what happens when they fail. MONTH 4 — System Design Learn: • Scalability • Load balancing • Caching • Sharding • Replication • Messaging • Rate limiting • Fault tolerance Design: → URL shortener → Chat system → Notification system → Video platform And explain the trade-offs. MONTH 5 — Production Learn: • Docker • CI/CD • Logging • Monitoring • Metrics • Tracing • Security • Cloud basics Deploy your applications. Production teaches lessons tutorials can't. MONTH 6 — Engineering Thinking Start asking: Why this database? Why this architecture? What happens if this service dies? What happens when traffic increases 100x? What happens when the network fails? What happens when two requests update the same record? These questions matter more than memorizing another framework. EVERY WEEK Build something. Read code written by better engineers. Debug something you don't understand. Write tests. Read documentation. Explain what you built. Repeat. The goal isn't to know every technology. It's to become the person who can learn a new technology quickly because the fundamentals are already there. That's what I think being a software engineer actually means.

Has anyone actually gotten better at coding by solving LeetCode every day, or does it mostly make you really good at solving LeetCode problems?

After working on distributed systems for years. I’ve learned one uncomfortable lesson: Most production incidents aren’t caused by the happy path. They’re caused by what happens when things go wrong. Here are 5 failure scenarios every backend engineer should design for: 1. Traffic suddenly spikes Your API handles 1,000 requests/sec perfectly. Then a flash sale starts. Now it gets 20,000. Without protection: • Requests pile up • Threads get exhausted • Database connections run out • Latency increases everywhere Solution: • Rate limiting • Load shedding • Queuing • Autoscaling • Backpressure 2. A downstream service becomes slow Your service is healthy. But the payment service takes 10 seconds to respond. Now your threads are waiting. Then more requests arrive. Eventually your service becomes unhealthy too. Solution: • Timeouts • Circuit breakers • Bulkheads • Fallbacks Never let one slow dependency take down your entire system. 3. Cache goes down Your application was designed around fast Redis reads. Redis suddenly disappears. Every request now hits the database. The database gets overloaded. Now your cache failure becomes a database failure. Solution: • Cache-aside • Graceful degradation • Request coalescing • Database protection A cache should make your system faster. It shouldn't be the reason your system stays alive. 4. A message consumer crashes The producer keeps publishing. The consumer is offline. Messages start accumulating. When the consumer comes back, it suddenly has thousands of messages to process. Solution: • Monitor consumer lag • Control concurrency • Use retry policies • Use dead-letter queues • Make consumers idempotent Recovery is part of system design. 5. Your database becomes the bottleneck You scaled your application servers. But every request still hits one database. Adding more application servers doesn't solve the problem. It can actually make it worse. Solution: • Connection pooling • Read replicas • Caching • Query optimization • Partitioning/sharding when necessary The fastest application in the world is useless if its database can't keep up. Good distributed systems aren't designed only for success. They're designed for failure. Which failure scenario have you personally dealt with in production?

I asked a developer: “How do you make sure only ONE server processes a job?” He said: “Use a boolean flag in the database.” Fair. Then I added: → 100 application servers → Job runs every minute → Any server can pick it up → Servers can crash → Network can timeout → Processing can take 10 minutes Now imagine: Server A checks: isProcessing = false Server B checks: isProcessing = false Both see the same value. Both start the job. You wanted: 1 execution. You got: 2. Now add 100 servers. Suddenly you have duplicate jobs everywhere. So you introduce a distributed lock. But then another question appears: What happens if the server holding the lock crashes? The lock remains. The job never runs again. So you add a TTL. Better. Until the job takes longer than the TTL. The lock expires. Another server starts processing. Now two servers are working on the same job again. Distributed locking looks simple. Until you start asking: “What happens when things fail?” That's usually where the real system design begins.