DEV Community: Stephen Jarso

How the Internet Feels Instant: CDNs, Load Balancers, and the Invisible Infrastructure Behind Every Fast App

Stephen Jarso — Fri, 18 Sep 2026 16:00:02 +0000

Your Server Doesn't Hate You.It's Just Miles Away.

Picture this:you just finished building a website.

Testing it on your own computer feels amazing.It is snappy-meaning it responds instantly,loading images and text in the blink of an eye.

Excited you launch it on the internet.Then your friend on the other side of the world tries to open it..It takes three painful seconds just to load the homepage.

Before you panic,take a breath:you didn't build a bad website.Your main computer systems(the server)is just physically far away, and the internet still has to obey the laws of physics.

Data doesn't teleport.It is a physical signal.To get from a computer center in Virginia to a phone in Singapore, your website's data has to pack its bags.It travels through thousands of miles of glass cables buried underground,dives deep water under the pacific ocean, and bounces across continents.Every single miles adds a tiny delay.
This is the exact problem a massive,hidden layer of global infrastructure exists to solve.

The engineers who built the internet didn't figure out how to make data travel faster than the speed of light.Nobody has cracked that yet.Instead, they did something cleverer:they figured out how to make the data travel less far.

This is the story of CDNs, edge servers, and load balancers.It is the invisible delivery system that quietly decides whether your favorite app feels instant or broken.

Let's actually try to understand how it works,without getting lost in the heavy tech jargon.

The Core Problem:Distance Equals Delay(latency)

Everytime you click a button or open a page on an app,your phone has to send a physical message to a computer(the server) on the other side of the world, and that server has to send a message back.

If your website's main server sits in Virginia and a user is browsing from Nairobi,that round trip across the globe takes time.Even if everything goes perfectly,the physical journey alone takes about a quarter of a second before the computer has even begun to process what you asked for.

That might sound fast,but think about everything on a modern webpage.A single page isn't just one file.It is made up of dozens of pieces:

Individual image and photos
The styling rules that make it look pretty
The hidden code instructions that make buttons work
Requests for live updates like prices or weather

If your phone has to make that massive global round trip for every single one of those pieces, it doesn't matter how well-written your website is.You are completely trapped by geography.

So, the tech world came up with a beautifully simple answer:stop making every single person talk to one lonely server on the other side of the planet.Instead, let's put copies of the website everywhere.

That is exactly what a CDN(Content Delivery Network) does.

CDNs: Your Content, Cloned Across the Planet

A CDN (Content Delivery Network) is simply a global team of helper computers spread across cities, countries, and continents. Each one holds a saved copy of your website.

When someone visits your site, they don't have to reach all the way back to your main computer (the origin server). Instead, they connect to the helper computer closest to their house.

Think of it like buying coffee. If you want a morning latte, you don't drive hundreds of miles to a central coffee bean factory. You go to the local coffee shop down the street that already has the beans roasted, ground, and ready to go. The CDN is that neighborhood shop, serving up your website from local stock.

In the tech world, these neighborhood shops are called PoPs (Points of Presence). A large CDN provider might have hundreds of these locations scattered around the globe, each packed with a small army of edge servers (the helper computers) waiting to hand out your content.

What Happens Behind the Scenes

When a user clicks on your site to see a picture, a silent game of telephone happens in milliseconds:

The Request: The user asks to see a photo on your site.
The Smart Shortcut:The internet automatically redirects their phone to the closest helper computer in their city.
The Quick Win (Cache Hit): If the helper computer already has a copy of that photo saved, it hands it over instantly. Total speed victory.
The Backup Plan (Cache Miss): If the helper computer doesn't have the photo yet, it quickly sprints back to your main origin server, grabs a copy, saves it for later, and hands it to the user.

The very first user who visits your site from a new city has to wait a tiny bit longer while the helper computer fetches the original file. But every single user after them gets the express lane, because the local shop now has it fully in stock.

Edge Servers: The Actual Machines Doing the Work

"Edge" is one of those tech words that sounds way more mysterious than it actually is. An edge server is simply a computer that is physically close to the person browsing your site. It sits at the outer "edge" of the global internet map, right where the users are, instead of being buried deep in a single, faraway data center.
These days, edge servers do a lot more than just hold onto static photos. Modern systems let you run actual code right there next to the user. Without making a giant trip back to your main server, an edge server can instantly:

Check if a user is logged in
Redirect someone to a different page
Show a user a new experimental feature to test if they like it
Custom-build a webpage on the fly

If you have ever used popular modern hosting tools like Vercel or Cloudflare, you have already put code onto the edge without even realizing it.

Caching: The Art of Not Doing Work Twice

All of this speed is powered by a concept called caching. The idea is beautifully simple: save the results of hard or expensive work, and hand out that saved copy instead of doing the work all over again.

The tricky part isn't saving the file—it's knowing when that file has become old and outdated. In fact, knowing when to stop trusting a saved copy is famously one of the hardest problems in all of computer science.

Here are the real-world strategies developers use to solve it, explained simply:

The Timer (TTL / Time To Live): You put a countdown timer on a saved file (like setting it to expire in one hour). Once the timer hits zero, the helper computer throws it away and grabs a fresh copy from the main server.
The Name Change (Cache Busting): If you update your website's code, instead of trying to delete the old file from millions of computers, you just give the new file a brand new name (like changing website-code.js to website-code-v2.js). The internet sees the new name, realizes it's a totally new file, and loads it instantly with zero glitches.
The Manual Panic Button (Purge APIs): If you make an urgent fix and absolutely cannot wait for a timer to run out, you click a button to manually tell the global network: "Drop the old copies right now."
The "Fix It Later" Trick (Stale-While-Revalidate): When a user asks for a page, the helper computer gives them the slightly old, saved version immediately so they don't have to wait. Then, while the user is happily reading, the computer quietly updates itself in the background so it's perfectly fresh for the next person.

If you have ever changed a setting to tell a server to save a file for an hour and then moved on with your day, congratulations: you were doing complex global systems engineering without even knowing it!

Load Balancing: Don't Let One Server Take the Whole Hit
While CDNs solve the "content is too far away" problem, load balancing solves a completely different nightmare: "too many people are trying to use the same computer at the same time."

Imagine a video goes viral or a massive online shopping event launches. Millions of people rush to click the exact same button at the exact same moment. If all those requests hit a single computer, that machine will overheat, run out of memory, and completely crash.

A load balancer is like a host at a wildly popular restaurant. Instead of letting a thousand guests crowd around a single waiter, the host smoothly distributes the guests across hundreds of open tables. It sits in front of a whole group of computers and decides which one is ready to handle the next visitor so that no single machine melts under pressure.

Here is how they distribute the crowd:

The Card Dealer (Round Robin): Requests rotate through the computers in a strict order, exactly like dealing cards around a poker table.
The "Who is Free?" Check (Least Connections): The system checks to see which computer is currently the least busy and sends the next visitor there.
The Familiar Face (IP Hash): The system ensures that a specific user consistently lands on the exact same server. This is super helpful so the website doesn't suddenly forget who you are mid-click.
The Doctor's Visit (Health Checks): The load balancer constantly pings all the computers to make sure they are feeling okay. If one computer quietly stops responding, the load balancer stops sending traffic to it entirely.

This health check is how websites survive a server dying at 3:00 AM without anyone noticing until the next morning. One computer goes down, the load balancer instantly reroutes the traffic to healthy computers, and the users never experience a single glitch.

Geographic Routing: How the Internet Knows Where You Are

Here is the part that feels like a magic trick. How does a request from a user in Nairobi automatically end up at a helper computer in Johannesburg, instead of accidentally flying all the way to a server in Frankfurt?

The answer is a trick called Anycast routing.

Instead of giving every computer on Earth a unique digital address, engineers give multiple helper computers around the world the exact same address.

It works less like a GPS tracking your location and more like the postal service. If you drop a letter into a mailbox addressed to a major grocery chain, the postal system naturally sends it to the closest distribution center, not one on the other side of the country. The internet's routing system naturally prefers the shortest, least congested path. It happens invisibly, before your code even has a chance to run.

How It All Fits Together
Here is the full picture of what happens in the blink of an eye when a user clicks on your website:

The Click: A user requests your website.
The Shortcut: The internet's postal system automatically routes them to the physically closest helper computer.
The Quick Check: That local helper computer checks its saved files (its cache).
The Fast Lane (Cache Hit): If it has the file, it hands it to the user instantly. Your main server never even hears about it.
The Backup Plan (Cache Miss): If it doesn't have the file, the helper computer sprints back to your main server headquarters.
The Traffic Cop: At headquarters, a load balancer greets the request and hands it to the server that is least busy.
The Return Journey: The server hands the file back, the helper computer saves a copy for the next person, and the user's page loads.

Every single layer exists to answer one question: how do we get this website to the user as fast and as reliably as possible?

Why This Actually Matters to You
You don't need to build your own global network to benefit from this knowledge. If you launch your projects on modern web platforms like Vercel, Netlify, or Cloudflare Pages, you are already using CDNs, edge computers, and smart routing without having to configure a single setting.

But understanding how the foundation works completely changes how you build things:

No More Mystery Bugs: You won't be surprised when a bug you "fixed" still shows up for some users. You will know it's just an old, saved copy stuck in a helper computer somewhere (a stale cache), not broken code.
Smart Choices: You will understand why simple things like photos should be saved everywhere aggressively, while live updates like bank balances shouldn't be.
No More Shrugging: You can actually think logically about why a website is running slow, instead of just shrugging your shoulders and blaming "the internet."

The next time your app feels completely instant to someone living on the other side of the world, remember that it isn't luck. It is a beautiful, silent relay team of helper computers, traffic cops, and smart routing decisions, all working exactly as designed, entirely out of sight.

Moving Beyond CRUD: Building a Geofenced Network Engine from Scratch

Stephen Jarso — Sun, 19 Jul 2026 19:34:36 +0000

Why I am Leaving Simple Web Apps Behind

Let’s be completely honest: There are only so many Todo apps, e-commerce clones, and standard REST/CRUD dashboards you can build before you start craving real engineering depth.

Lately, I have been shifting my focus toward networking, lower-level protocols, and infrastructure security. I wanted my next portfolio project to be a massive learning journey something that forced me to think about raw binary parsing, kernel-space performance, cryptographic handshakes, and data pipeline observability.

So, I decided to bypass standard application-level programming and design a Software-Defined, Geofenced Mesh Network with an AI Anomaly Detection Layer.

Here is the architectural blueprint of how I am combining custom socket programming, cryptographic spatial data, and neural networks into an omniscient, real-time "God-View" system.

The Architectural Vision

Imagine a secure private network overlay where data routing is strictly bound by physics and geography. Devices acting as nodes connect to an edge broker and transmit real-time telemetry. However, data packets are cryptographically verified based on physical coordinates.

If a malicious actor steals credentials and attempts to access the network from an unauthorized region, or uses an automated script to spoof their GPS, the infrastructure detects it instantly. A neural network constantly evaluates the physical location claim against raw network characteristics (like latency jitter and packet transit variations). If a discrepancy is found, the connection is instantly severed.

To monitor this entirely stateful environment, the central control server pipes live infrastructure logs over WebSockets to a web-based "God-View" dashboard. This top-down view visualizes real-time data tunnels lighting up, global traceroute paths, and localized security flags mapped over an interactive geographical grid.

The High-Performance Tech Stack

To manage thousands of concurrent streams without high latency or packet drop, the architecture skips generic web frameworks in favor of system-level technologies:

The Core Network Engine (Go): I chose Go (Golang) for the ingestion engine. Go’s native network stack (net package) paired with ultra-lightweight concurrent goroutines allows it to manage thousands of open TCP/UDP sockets out of the box using minimal memory. The engine’s primary job is to strip framing headers, parse raw binary payloads, and handle connection lifecycles.
The Cryptographic Tunneling Layer (WireGuard): Instead of routing sensitive telemetry through slow, user-space proxy code, the application interfaces directly with WireGuard. WireGuard handles state-of-the-art, kernel-level encrypted virtual interfaces. This allows us to dynamically spin up, configure, and tear down secure tunnels between edge IoT devices and the backend infrastructure programmatically.
The Security Brain (Python + PyTorch): How do you catch a bad actor faking their GPS coordinates? You use a neural network. I am building a lightweight Anomaly Detection Autoencoder in PyTorch hosted behind a high-speed gRPC interface. The Go engine streams network telemetry metrics such as round-trip time (RTT), Time-to-Live (TTL) changes, and network jitter—to the Python model. The neural net determines if the physical location claim perfectly correlates with the physical realities of the network packet’s transit path.
Telemetry Storage (Redis & VictoriaMetrics): Standard relational databases (like MySQL) or document stores (like MongoDB) will choke under thousands of streaming location writes per second. I am utilizing Redis for sub-millisecond coordinate caching and geographical command filtering (GEOADD/GEORADIUS), alongside VictoriaMetrics to aggregate long-term time-series network health data.

Defining the Protocol Data Blueprint

To optimize performance, we don't send heavy JSON payloads over the raw sockets. Instead, we use a compact, structured binary frame format to keep our network footprint small and predictable.

Each device telemetry packet is exactly 24 bytes:

Offset (Bytes)	Field Name	Data Type	Description
`0x00 - 0x03`	`DeviceID`	`uint32`	Unique tracking identifier for the node.
`0x04 - 0x11`	`Latitude`	`float64`	Encoded high-precision GPS latitude coordinate.
`0x12 - 0x1F`	`Longitude`	`float64`	Encoded high-precision GPS longitude coordinate.
`0x20 - 0x23`	`Timestamp`	`uint32`	UNIX epoch timestamp of packet transmission.

Let’s Discuss!

This project is taking me completely out of my comfort zone, and I am bound to run into significant architectural hurdles especially when trying to keep serialization latency low while piping network metrics into Python for evaluation.

Have you ever designed a custom binary packet system or handled live geospatial multi-node streaming? What tricks do you use to manage persistent state safely across asynchronous networking platforms?

Let me know your thoughts, tips, or architecture critiques in the comments below!

Confessions of a Dev #2:The Interview Answer That Haunts Me

Stephen Jarso — Thu, 23 Apr 2026 03:44:43 +0000

You know that feeling — walking out of an interview, and by the time you hit the elevator, your brain already starts replaying that one question.

The one where you said something… fine. Acceptable. Professional.

But deep down, you know you had a killer answer in you. The honest one. The clever one. The one that would've made the interviewer lean in and say, "Tell me more."

Instead, you played it safe. You gave the textbook response. You talked about "process improvement" and "team collaboration" like a LinkedIn post come to life.

And now, days later, you're still thinking about what you should have said.

Not because you lied. But because you held back.

Here's mine.

I was interviewing for a Flutter role. Everything was flowing — architecture, state management, animations. Then came the question:

"What do you use for the backend?"

What I said:
"Dart."

Just… Dart. Like it's a backend. Like that's a normal thing a reasonable person would say.

What I should have said:
"Firebase. Or if I need more control, a custom API with Node or Go. But Dart? Only if I'm using Serverpod or Dart Frog — and even then, I'd clarify that's not the same as 'Dart by itself.'"

The interviewer paused. Typed something. Moved on.

And me? I sat there, smile frozen, already replaying the horror in slow motion.

So here's where I leave you hanging:

Did I get the job?

…That's for Dev Confessions #3.

Now your turn — drop in the comments:
What's one thing you said in an interview that still makes you cringe? And what should you have said instead?

Confessions of a Dev #1:I Went Blank When Asked "What's an API?"

Stephen Jarso — Wed, 15 Apr 2026 02:39:43 +0000

Last week, a friend asked me something so basic, so fundamental that i should have been able to answer it in my sleep.

"Hey, quick question...what exactly is an API?"

Not a trick question. Not an interview. Just two devs talking.

And I went blank.

I’ve built REST APIs. I’ve authenticated with JWT.

But in that moment? Nothing.

So I did the thing we all do when our brain short-circuits:

"I mean… I know how they work? Or what they do? You know."

We both laughed. He nodded like he understood. But I knew: I had failed the simplest test of all.
The Problem (It’s Worse Than You Think)

When a non-technical person asks “what’s an API?”, you can use a waiter or a mailman analogy. They’ll be happy.

But when a technical person asks, they’re not looking for a metaphor. They already know what a server is, what HTTP is, what JSON is. They’re asking for the essential definition – the crisp, precise, almost philosophical answer.

And that’s way harder.
Because APIs are so obvious to us that we’ve never actually articulated them. We just… use them. The definition lives in our fingertips, not our tongue.

So after that humiliating moment, I went home and forced myself to answer properly. Here’s what I came up with.
What I Should Have Said (Technical Edition)
The One-Sentence Definition (Crisp & Precise)

“An API is a defined interface that specifies how one software component can interact with another – including valid requests, expected responses, and the underlying protocol (usually HTTP).”

That’s the technical answer. No fluff. No waiter.
The Slightly More Technical Answer

“An API is a contract between a client and a server. It says: ‘If you send me a request in this shape, to this URL, with these headers, I’ll send you back a response in this shape – and here are the status codes to tell you what happened.’”

The “Ah, Right” Analogy (Still Technical)

“Think of a database query language like SQL. You send a SELECT statement, you get a result set. An API is the same idea, but over HTTP – and instead of tables, you work with resources (users, orders, products).”

The Shortest Possible Answer

“An API is a layer that abstracts an implementation behind a set of publicly accessible operations.”

That one would have made me sound smart. But I didn’t say it. I said “uh… you know.”
Why Technical People Go Blank on Basic Definitions

It’s not because we don’t know. It’s because:

We think in use cases, not definitions – “An API is what I call to get user data” is not a definition, it’s an example. But that’s how our brains store it.
We confuse “how it works” with “what it is” – I could have explained the HTTP request cycle, JSON serialization, status codes, rate limiting, and authentication. But that’s not what an API is. That’s how you use one.

3.We’ve never had to define it – In school, they teach you syntax, not definitions. In work, you just build things. No one ever says “define API” in a sprint planning meeting.

The Real Lesson (For Devs, By a Dev)

Knowing how to build something is not the same as knowing how to define it.

The best developers can do both. They can talk about implementation and they can zoom out to the 10,000-foot definition without stumbling.

So here’s my challenge to you, fellow dev:

Without looking it up, define these terms in one sentence – out loud, right now:

    HTTP

    JSON

    JWT

    DOM

    TCP

If you can’t, welcome to the club. Let’s practice together.
Call to Action (Your Confession)

Now it’s your turn.

What basic technical question made you go blank in front of another developer?

Drop your confession in the comments. No judgment. Just devs being honest.

This is Confessions of a Dev. We’ve all been there.