Omkar

Bloom Filters: the data structure that lies… but in a useful way. Think of it as "probably yes" engineering. I broke it down here 👉 triggeredcode.github.io/paper-cuts/blo…

> 03_the_ultimate_fix Cloudflare engineers patched NGINX to hand off both `open()` and `read()` to the background thread pool. The worker thread fires off the request and instantly returns to serving other users. Once the SSD finishes, the background thread uses an event notification (epoll) to wake the main loop up.

> 02_failed_attempt NGINX had Thread Pools to move `read()` to a background thread. But `open()` must traverse directory structures. As Cloudflare noted, a single cache miss means the OS makes 6 separate disk reads just to walk down the folder tree to find the file's metadata, compared to just 1 read for the actual data. Standard NGINX ran this heavy `open()` on the main loop. The disk lookup bottleneck remained.

Morning Guys, Yesterday I dug into this classic Cloudflare piece: blog.cloudflare.com/how-we-scaled-… And wow... still gold. My takeaways: 1️⃣ Optimize for Outliers Forget averages. p99 latency is where the skeletons hide. Systems can look “healthy” while random users suffer massive delays. Fixing the worst‑case is the real game. 2️⃣ Hardware Lies Specs ≠ reality. Even enterprise SSDs randomly spike latency thanks to internal quirks. Scale exposes chaos. 3️⃣ Trace the Pipeline Optimizing one call is useless if another upstream bottleneck drags you down. Profile everything ... open(), read(), write()..the whole chain.

🌅 Morning Guys, First off, a massive shoutout to @Hi_Mrinal—you really inspired me to get my curiosity back and start diving deep into engineering blogs again. Thanks for the spark, buddy! 🙌 Putting that curiosity right to work, I spent yesterday reading Figma’s famous write-up on their multiplayer architecture, and it absolutely made my day. I went in with a pretty naive mental model. I was thinking: "How difficult could it really be? You just sync some JSON state over a WebSocket, resolve a few conflicts, and call it a day, right?" By paragraph three, I was hit with Operational Transformations (OT), CRDTs, fractional indexing, and reparenting cycle detection. Instead of feeling overwhelmed, my curiosity absolutely spiked. The engineering rabbit hole was fascinating. Here is the story of how they solved it: ❌ [THE GOOGLE DOCS TRAP] ━━━━━━━━━━━━━━━━━━━━━━ My first thought was, "Google Docs solved multiplayer a decade ago, why not just copy their homework?" Google Docs uses Operational Transformation (OT). It’s brilliant for fine-grained text editing, but the mathematical correctness proofs required for OT absolutely explode in complexity just for simple insert/delete operations. Figma isn't a text editor; it's a canvas of objects. Implementing OT would have been a massive bottleneck. ✳️ [THE PURE CRDT ILLUSION] ━━━━━━━━━━━━━━━━━━━━━━ So, if not OT, then you might think this is a classic use-case for CRDTs (Conflict-free Replicated Data Types). But even that isn't true! Pure CRDTs are explicitly designed for completely decentralized, peer-to-peer systems where nobody is in charge. Figma realized they didn't need that. They have a server, a central authority already exists. So, they built a beautiful hybrid approach. They adopted the mathematical convergence guarantees of CRDTs, but dropped the heavy overhead required for true decentralization. ↳ The ultimate takeaway: The "standard" textbook algorithm isn't always the right answer. Your specific architecture and constraints dictate the solution. THE FOUR PILLARS If you want to see a masterclass in practical system design, you should definitely read the full blog. They break down the architecture into these four specific problems: ▹ Syncing Object Properties (Surgical diffs over full state) ▹ Syncing Trees of Objects (Detecting infinite reparenting cycles) ▹ Reordering Objects (The magic of fractional indexing) ▹ Implementing Undo Let me tell you... that last point on Undo is the most mind-bending piece of logic I've read in a long time. The way they dynamically recalculate history stacks the exact second you press "Undo" to protect your coworkers' edits is pure genius. Highly recommend giving it a read! » figma.com/blog/how-figma…

So, I was looking at my network tab the other day, watching requests go back and forth, and a thought hit me... Cookies. Auth tokens. Session IDs. Tons of headers. We are sending this exact same data on every single HTTP request. It's like having to show your ID to your own mom every time you walk into the kitchen just to prove you live there. It just feels like a massive waste of bandwidth. I caught myself thinking: Wait, if HTTP is so forgetful (stateless) and forces us to manually attach all this redundant data every single time, why don't we just use WebSockets for everything? Just connect once, leave the pipe open, and stop spamming headers. So, I went down a rabbit hole to figure out why we don't just do that. And it turns out, picking between stateful and stateless isn't some deep, unbreakable networking rule. It’s just a trade-off. You are basically just choosing exactly how you want your server to suffer. Here is the mental model of how it actually works..

━━━━━━━━━━━━━━━━━━━━━━━ THE IDENTITY LAYER OAUTH FORGOT ━━━━━━━━━━━━━━━━━━━━━━━

━━━━━━━━━━━━━━━━━━━━━━━ OAUTH: A HISTORY OF BOTTLENECKS ━━━━━━━━━━━━━━━━━━━━━━━

⩥ fundamentals ⎮ Authorization vs Authentication ━━━━━━━━━━━━━━━━━━━━━━━ TWO GATES, NOT ONE ━━━━━━━━━━━━━━━━━━━━━━━

5/5 me (client) → millions(+) of servers. one port. → real limits: RAM + file descriptors. → just stop trusting OS autopilot. the server → same deal millions on port 443 → just hardware in the way. what i got wrong ↓ ✗ "65,535 is a hard cap" ✗ "HTTP/2 multiplexing was the unlock" what was true the whole time :: ✓ it's always been the 4-tuple ✓ OS was just too lazy to use it "the protocol handed us the whole world. the server built for it. my OS just forgot to unlock the door"

4/5 "okay but my script still crashes at 28k.. if the wall isn't real, WHY?" because the OS is lazy. instead of reusing ports across different destinations, it just... grabs a new one. every time. 1 → 2 → 3 → ... → 65,535 → 💀 port exhaustion. the fix bind() to a specific local port + SO_REUSEADDR → OS stops hoarding fresh ports → same port, million(+) destinations → no crash ✓ the protocol was never broken. we just had to stop letting the OS run on autopilot.

1/5 servers hold millions of connections on a single port. so i asked — how many different servers can i, the client, connect to? A) ~1,000 B) ~65,535 C) millions(+) or more i thought B confidently. wrongly.. ↓ it gets embarrassing

Everything lives on TCP or UDP

HTTP Evolution

Going through fundamentals again !! How data moves over HTTP?