every time your phone shows "5 ubers within a mile" or yelp pulls up restaurants near your dot on the map, somewhere in the backend a system is solving the same problem: given a point on earth, find all the other points close to it, fast. the naive answer is to scan every row in your database, compute the haversine distance to the query point, and return everything within some radius. this works…
a cua (computer use agent) is just an llm that controls a browser. you give it a task like "log into some saas dashboard and screenshot the encryption settings", it takes a screenshot, sends the screenshot to claude with a list of tools ( click , type , scroll ), claude returns a tool call like click(x=420, y=180) , you apply that to the browser, take another screenshot, and loop. that's the whole…
aight, let's talk about remote desktops and why the web makes everything complicated (but also kinda cool). what you'll take away quick pointers so you know what to look for as you read: vnc is just a protocol over tcp. server captures the screen, client sends input — and only the changed pixels ship. browsers can't open raw tcp connections. sandboxed to http and websockets — that one constraint…
dropbox is one of those apps that feels totally simple until you start designing it. you upload a file, it shows up on your other devices. share it, someone else sees it. but every step here has a real engineering question buried in it. 50GB uploads can't just be a single POST. sharing 100k files across users can't just be a list scan. and getting bytes from a virginia data center to a tokyo…
aight so today we're talking about id generators. seems boring on paper, but stay with me — this is one of those topics where every line of complexity comes from a real production problem someone hit at scale. and the cool part is the entire problem statement collapses to: write a function that spits out something unique every time it is invoked . that's it. no service, no microservice, no fancy…
a system that looks deceptively simple on the surface but hides a bunch of interesting engineering decisions underneath. you know the page — when you tap #sunset on instagram and see the name, total posts, and a grid of top photos. let's walk through how to actually build it. what you'll take away quick pointers so you know what to look for as you read: a guiding principle saves you from the cap…
the tiny number on your messaging icon: designing the unread sender count a system that looks deceptively simple on the surface but hides a bunch of interesting engineering decisions underneath. you know that little number on your messaging icon — the one that tells you how many new people messaged you. let's walk through how to actually build it. what you'll take away quick pointers so you know…
every system design conversation eventually circles back to bit.ly. it's the canonical "looks dead simple but isn't" service — take a long url, hand back a short one, redirect on click. the surface is straightforward. then you start asking how it scales to a billion urls and 100M daily active users, and the design gets way more interesting. this is a full walkthrough — requirements, api, the…
where do remote locks even fit in? before we jump into remote locks and distributed locks, lets take a step back and understand where they fit in. there's a beautiful logical evolution here that most people miss. when you have multiple threads that need to synchronize, you use a mutex or a semaphore. why? because threads share the same memory space, so an in-memory primitive is the closest…
queues are one of those things that sound dead simple from the outside. you push stuff in one end, you read it from the other end, fifo, done. but the moment you try to build anything real on top of a queue, you realize there are like five layers of decisions hiding under the hood. and one of the biggest myths people walk around with is that queues are fifo . they are not. not in any system you'd…
scaling reads sounds boring on the tin and then you realize it's basically every system design problem in disguise. the moment your app gets even a little popular, reads outpace writes by 10×, then 100×, then 1000× — and your single database starts crying. this post walks through the actual ladder you climb to handle it: from "just add an index" all the way up to global CDNs, with the trade-offs…
so we all know most databases store data in b+ trees, but why ? not just sql databases either - even non-relational databases like mongodb leverage b+ trees to store their data. mongodb's storage engine wiredtiger serializes collection data as b+ trees on disk. but let me tell you why there was even a need to introduce a data structure like b+ trees in the first place, and how this actually works…
why another database? your first question should hit you: "why on earth should we do this?" like dynamodb exists, redis exists, valkey exists, this exists, that exists. why do i have to do this? but instead of looking at it from a lens of "hey why the world needs it," let's look at it from a mental model perspective. the core essence of this is storage-compute separation . that's our biggest…
Caching: It's Not Just About Memory Myth-busting time : Caching doesn't mean in-memory. I see this confusion everywhere. We accept data staleness in exchange for avoiding expensive operations. Every time you cache something, you're saying 'I'd rather serve data that might be 5 minutes old than wait 2 seconds for a database query What Caching Really Means Cache = saving expensive operations .…
Why should we care about DNS? Because it's one of the most beautiful pieces of software ever written - it made the internet what it is possible today by giving a human-readable name to every single thing out there, not requiring us to remember weird IP addresses of machines. But here's the thing: most people think DNS is just "domain name to IP address lookup." That's like saying the internet is…