Amit K.

Google built QUIC as they got tired of waiting for the internet to catch up :) Let me explain what it is, why it is needed, and how you can see it in action. Imagine you are watching a live video, and a frame gets lost. Instead of skipping it and moving on, the player waits for retransmission and shows a frustrating spinner. Now, in live video, losing a frame or two is fine, but a pause is much worse UX. This is where QUIC comes into the picture and solves the problem. QUIC is a transport protocol that runs on top of UDP, and you can think of it as TCP's faster cousin - sorry :) It was designed from scratch to eliminate bottlenecks that make web browsing feel sluggish, especially on mobile networks. QUIC allows you to 1. have multiple streams in one connection 2. resume connections instantly, and it takes literally 0-RTT 3. seamlessly switch between WiFi and cellular without dropping the connection Here's a real scenario - say, you are on a video call while walking from WiFi to cellular. With TCP/HTTP/2: - WiFi signal weakens - connection drops - Phone switches to cellular - new IP address - Video app must re-establish the entire connection - Handshake + TLS - 3-5 seconds of "connecting..." screen - Call resumes But, with QUIC, - WiFi signal weakens - QUIC detects degradation - Phone switches to cellular - QUIC migrates connection to new IP - connection migration to the switch seamlessly - maybe 200ms hiccup, if anything - call continues without interruption If you see pages loading instantly, or video not buffering, or an app that stays connected as you move around, very likely it is QUIC-based (but do check once). To see this in practice, you can actually run a QUIC server locally in your preferred programming language and benchmark. Like always, let LLMs to do the grunt work. Hope it helps.

1,320

34 Comments

CDC comes up a lot in system design interviews. It solves the very real problem of propagating database changes to other systems without constant polling. But what happens when your interviewer decides to probe into implementation? Do you really understand how it works? Most candidates I see can parrot the basics - "CDC captures database changes in real-time" - but they fall apart when asked how it actually works. Let's see how this is done using Postgres as an example. PostgreSQL already logs every transaction to its Write-Ahead Log for crash recovery. Logical decoding (PostgreSQL's feature that converts raw WAL changes into structured, readable events) reads these WAL entries and converts them into structured change events. Debezium is a popular open-source CDC platform that connects to your database and streams these changes to Kafka. When you set up Debezium, it first takes a consistent snapshot of your database, then immediately starts streaming from the exact WAL position where that snapshot ended. The timing eliminates race conditions and missing data between the snapshot and the stream. Logical replication slots make this reliable. PostgreSQL holds onto WAL segments until your CDC consumer confirms it processed them. Your Debezium connector can crash, get redeployed, or go offline for hours, but when it comes back, it resumes from the last confirmed LSN offset. Debezium transforms these WAL entries into standardized change events and pushes them to Kafka. Each event includes the LSN for ordering guarantees. Your downstream systems - search indexes, caches, analytics - consume these events and stay synchronized without ever polling the primary database. The best part is the performance impact is minimal because you're getting a free ride on PostgreSQL's existing durability guarantees. The WAL exists regardless of whether you're using CDC. Once you understand the WAL + logical decoding combo, CDC stops feeling like black magic.

843

33 Comments

Most students know me for competitive programming, but many (except those in AZ Premium) haven’t seen my other side. In the premium classes, I’ve taken multiple sessions on system design—focusing on analyzing trade-offs and solving real-world problems, not just coding challenges. I’ve now started a Placement Series on YouTube. The latest video is on multithreading in system design—covering fundamentals, common pitfalls, and how to reason about concurrency. Watch it to strengthen your design thinking beyond algorithms. #AZ #AZPremium

155

1 Comment

If you want to become better at system design rounds, definitely read these 10 case studies by Neo Kim. I am 100% sure, they will make you smarter for your next interview.  1/ How Meta Achieves 99.99999999% Cache Consistency: → https://lnkd.in/e88kUZAm 2/ How Uber Computes ETA at Half a Million Requests per Second: → https://lnkd.in/eVKV2ePC 3/ How PayPal Was Able to Support a Billion Transactions per Day With Only 8 Virtual Machines: → https://lnkd.in/eqcb7MpP 4/ How YouTube Was Able to Support 2.49 Billion Users With MySQL: → https://lnkd.in/efmJw4Dx 5/ How WhatsApp Was Able to Support 50 Billion Messages a Day With Only 32 Engineers: → https://lnkd.in/gRqBgXfc 6/ How Uber Finds Nearby Drivers at 1 Million Requests per Second: → https://lnkd.in/eeqH9Hjh 7/ How Stripe Prevents Double Payment Using Idempotent API: → https://lnkd.in/erMkqwq4 8/ How Google Ads Was Able to Support 4.77 Billion Users With a SQL Database: → https://lnkd.in/efnSvwJp 9/ How Amazon S3 Achieves 99.999999999% Durability: → https://lnkd.in/eutGiK35 10/ How Slack Works: → https://lnkd.in/eATMDjrK

249

21 Comments

Stripe, Avoiding Double Payment to Customers💰 When collecting payments from customer via Stripe API, 3 error scenarios can happen, 1. The initial connection could fail as the client tries to connect to a Stripe server 2. The call could fail midway while the server is fulfilling the operation, leaving the work in limbo 3. The call could succeed, but the connection break before the server can tell its client about it To ensure successful payment, Client retries the request which can lead to double payment (as per scenario 3) To prevent double payment, Stripe accepts "idempotency key" into API header. Here is how it works, - Client generates a unique ID (as Idempotency-Key) to uniquely identify that operation and sends it up to the server along with the normal payload. - The server receives the ID and correlates it with the state of the request on its end. - If the client notices a failure, it retries the request with the same ID, and from there it’s up to the server to figure out what to do with it. If we consider our sample network failure cases from above: 1. On retrying a connection failure, on the second request the server will see the ID for the first time and process it normally. 2. On a failure midway through an operation, the exact behavior is heavily dependent on implementation, but if the previous operation was successfully rolled back by way of an ACID database, it’ll be safe to retry it wholesale. 3. On a response failure (i.e. the operation executed successfully, but the client couldn’t get the result), the server simply replies with a cached result of the successful operation. This is idempotence in Action, Guaranteeing “exactly once” semantics 🤔 over to you, for prolong outages retries will make it worse. How to prevent it? Let me know in the comments! 👇 --- You've got System Design skills but showcasing them in 60 minutes interview is a completely different challenge for e.g. where to start? How much time to spend on HLD vs LLD etc Let me share a FREE 7-day email course that provides a step-by-step framework for acing your 60-minute System Design interview 📣 Join 1700+ subscribers and sign up for the course to learn time allocation to demonstrate full range of design skills (link in comments 👇)

131

25 Comments

𝐔𝐧𝐩𝐨𝐩𝐮𝐥𝐚𝐫 𝐨𝐩𝐢𝐧𝐢𝐨𝐧: In 12 months, your dev team won’t be writing code. They’ll be managing agents that do. Sounds extreme, but let me explain. The way we build software is going through a fundamental shift. We’re moving from engineers-as-coders to engineers-as-architects. While agents handle every line of logic, engineers are designing how these agents work together in a unit. At SpotDraft, we already see this in action. Our teams are experimenting with cloud agents that handle: → Clause extraction → Risk classification → Suggesting redlines → Even summarising entire contracts Each one is like a junior dev with a very specific job. 𝐇𝐞𝐫𝐞’𝐬 𝐰𝐡𝐞𝐫𝐞 𝐈 𝐬𝐞𝐞 𝐨𝐮𝐫 𝐢𝐧𝐝𝐮𝐬𝐭𝐫𝐲 𝐡𝐞𝐚𝐝𝐢𝐧𝐠: In 12 months, a single engineer will manage 5 - 8 cloud agents like this. Their job won’t be to write low level code, it’ll be to review, quality-check, and fine-tune what these agents output. I think of it as a shift from builder to orchestrator. The question isn’t: “Will AI take my job?” It’s: “How good am I at managing a team of non-human contributors?” Are you training your engineers to think like quality checkers?

131

6 Comments