DEV Community: Zamira Dzhatdoyev

Someone Tried to Knock a Company Offline With 7.3 Terabits Per Second of Garbage, and the Company Barely Noticed

Zamira Dzhatdoyev — Wed, 08 Jul 2026 16:54:22 +0000

On November 18, 2025, ChatGPT went down. So did Spotify. So did a significant chunk of the websites you probably use without thinking about them. The outage lasted nearly six hours, and the cause wasn't a cyberattack or a fiber cut or a failed data center. It was a single oversized configuration file — a file for a bot management feature — that crashed proxy servers globally across one company's network.¹

That company was Cloudflare. And the fact that one company's configuration file could take down ChatGPT and Spotify at the same time tells you something important about how the internet actually works.

One company, twenty percent of the internet

Cloudflare is not a household name, but it is, in a very literal sense, everywhere. The company currently manages roughly 20 percent of all global internet traffic, protects over 41 million websites, and operates the largest managed DNS service in the world, with data centers in 337 cities across more than 100 countries.²

To understand what that actually means, it helps to understand what Cloudflare is doing for all those websites. When you type a URL into your browser, your request doesn't go directly to the website's server. It goes to Cloudflare first. Cloudflare checks the request, decides whether it looks legitimate, serves a cached version of the page if it has one, and only forwards the request to the actual origin server if it passes. From the website's perspective, the world sends requests to Cloudflare, and Cloudflare sends them on. From the attacker's perspective, the same is true. To attack a website sitting behind Cloudflare, you have to attack Cloudflare.

Think of it like a building that has replaced its own front door with a service desk staffed by someone whose entire job is to decide who gets in. Most visitors walk up, check in normally, and get waved through without noticing any delay. A few are turned away. And occasionally, someone shows up with a battering ram — except the service desk is made of something the battering ram can't touch, because it was designed specifically to absorb battering rams.

That service desk is what the internet's entire threat defense increasingly runs through. Which is exactly why a bad configuration file there makes ChatGPT disappear.

What a DDoS attack actually is

A DDoS attack, distributed denial of service, is the digital equivalent of filling a road with so many cars that nobody can actually drive on it. The goal isn't to break anything. It's to overwhelm — to flood a target with so much fake traffic, from so many sources at once, that it can't separate real visitors from noise, and falls over trying to keep up.³

The "distributed" part matters. A single computer can only send so much traffic. But a botnet — a network of thousands or millions of devices that have been quietly compromised without their owners knowing, and can be commanded all at once — can send an enormous amount. The compromised devices can be anything: home routers, smart TVs, security cameras, servers. Their owners have no idea. At some point, someone sends a command, and all of them start flooding the same target simultaneously.

In May 2025, Cloudflare blocked what was at that point the largest DDoS attack ever recorded: 7.3 terabits per second of traffic aimed at a single target.⁴ To put that in context: Cloudflare's total network capacity is 500 terabits per second. The largest attack ever recorded used up about 1.5 percent of what they keep available on standby, at all times, specifically for this purpose.

The attack wasn't unusual in kind, just in size. Cloudflare blocks an average of 209 billion cyberthreats per day.⁵ The 7.3 terabit attack was a record for scale, not for type.

How the defense actually works, and why no human is pressing a button

Here's the part that I find genuinely interesting, because it sounds like it shouldn't be possible at the speed required.

If an attack peaks at 17 million requests per second — which Cloudflare has also absorbed — there is no version of this where a security engineer sees a dashboard spike and manually intervenes in time. By the time a human noticed, the attack would have been ongoing for seconds or minutes, and the damage would already be done. The system has to decide, on its own, in real time, whether each request is legitimate or part of an attack.

Cloudflare's defense layer watches every packet flowing through its network. When it detects traffic that matches an attack pattern — wrong protocol, unusual rate, suspicious source distribution — it builds a fingerprint of what the attack looks like and compiles a filtering rule specific to that fingerprint. That rule starts dropping matching packets automatically. And once the attack stops, the rule expires and deletes itself. The system writes its own temporary code, runs it, and cleans up after itself, without anyone pressing a button.⁶

The reason this can happen at all is the same reason Cloudflare's configuration file outage was so impactful: every one of Cloudflare's servers runs this logic independently, not as a centralized system waiting for instructions from headquarters. Each server detects threats locally, shares what it's seeing with nearby servers, and acts on what it observes, which means the defense scales automatically to wherever the attack is heaviest, and there's no single location you could disable to turn it off.

This is the architectural tradeoff that gives Cloudflare both its power and its fragility. A distributed system with no central point of failure is very hard to take down deliberately. It is also very sensitive to a bad configuration file, because that file propagates everywhere, across every server, before anyone realizes something is wrong.

What the November outage actually tells you

The 2025 outages are worth recognizing, because they illustrate something that doesn't come up often enough in conversations about internet infrastructure.

The internet's resilience is real. Redundancy, failover systems, distributed architecture... these things work, and they protect against most of what goes wrong. But the same architecture that makes Cloudflare resistant to external attacks makes it extremely efficient at propagating its own mistakes. A bad configuration that touches every server simultaneously is, in some ways, a harder problem than a DDoS attack, because a DDoS comes from outside and can be fingerprinted and blocked. A bad configuration is inside the system already, doing exactly what it was told.

The November outage was caused by a configuration file that was too large. Not a malicious hack; just a file that was bigger than the proxy servers were built to handle, deployed across a global network before anyone caught it, taking down services used by hundreds of millions of people for six hours.

That's the honest picture of what it means for one company to sit between the internet and 20 percent of its traffic. The protection is real, the scale is wildy impressive, and the consequences of getting something wrong are proportional to exactly how much of the world runs through your network.

Why this matters beyond the technical details

There's a version of this post that just recites impressive numbers about attack sizes and makes Cloudflare sound invincible. That version would be missing the point.

The more interesting thing is what Cloudflare's existence tells us about how the internet has evolved. The original vision of the internet was decentralized: no single point of failure, no central authority, traffic routed freely around damage. What's actually emerged, over decades of organic growth and practical tradeoffs, is something more complicated: a network that is still technically decentralized at the infrastructure level, but runs increasingly through a small number of companies whose architecture, configuration decisions, and uptime directly determine whether most of the internet is working on any given day.

Cloudflare didn't plan to become a load-bearing wall for 20 percent of global internet traffic. It became one because it was genuinely good at what it did, and because the economics of internet infrastructure reward centralization. One company doing security well at scale is cheaper for everyone than every website doing it separately.

The tradeoff is that one company's bad day is now, occasionally, everyone's bad day. That's not a reason to be alarmed. It's just a reason to understand what's actually holding the internet up.

Footnotes

¹ On the November 2025 Cloudflare outage caused by an oversized bot management configuration file, which impacted ChatGPT, Spotify, and other major services for nearly six hours. DemandSage: Cloudflare Statistics 2026

² On Cloudflare's global network footprint, traffic share, and DNS market position. SQ Magazine: Cloudflare Statistics 2026

³ On how DDoS attacks work and the role of botnets in amplifying attack volume. Cloudflare Docs: How DDoS Protection Works

⁴ On the May 2025 record-breaking 7.3 Tbps DDoS attack and Cloudflare's network capacity context. Cloudflare Blog: Defending the Internet

⁵ On Cloudflare's daily threat mitigation volume. IP With Ease: Cloudflare DDoS Protection

⁶ On Cloudflare's autonomous fingerprinting and self-expiring mitigation rules. Cloudflare Blog: Defending the Internet

Someone Was Testing My Live App While I Was Asleep

Zamira Dzhatdoyev — Mon, 06 Jul 2026 23:39:14 +0000

I want to start with the comment, because the comment set the tone for everything that followed.

It arrived on a GitHub issue in a repo that wasn't even the right project, filed by a dev.to reader who had apparently been quietly poking around my live deployment. It opened with "Heyho kid, isn't this like summer break or something?" and proceeded to describe, in the cadence of a friendly riddle, several things that were wrong with my application. It mentioned logs. It mentioned auth. It mentioned something about an axios interceptor that it found "funny."

It had the energy of a Saw trap, but polite. Like if Jigsaw also genuinely wanted you to pass.

I had never had anyone inspect my work like that before. As a newcomer to actually shipping things, you build in a kind of comfortable bubble where the only person who ever really uses what you made is you. Nobody is looking for the gaps. Nobody is checking the locks. And then, without warning, someone was — quietly, while I was going about my day, entirely without my knowledge — and they left a note.

It was humbling in a way I wasn't prepared for.

What they actually found

The comment flagged three things: a 422 error crashing the frontend, some kind of auth issue, and something subtle in the token refresh logic.

The 422 crash was quick to find once I looked. A 422 is an HTTP status code meaning "I understood your request but something about the data you sent me is wrong."¹ When FastAPI validates incoming data and something doesn't pass — a password that's too short, a severity rating outside the allowed range — it doesn't just say "validation failed." It sends back a detailed list of objects describing exactly which field failed and why, something like [{"loc": ["body", "password"], "msg": "too short", "type": "string_too_short"}]. My frontend was taking that list and passing it directly to React to render as text. React can render strings as text. It cannot render a JavaScript object as text — it just crashes, the way a printer crashes if you hand it a sandwich instead of paper. Fix: check whether detail is a string or a list before trying to display it, and if it's a list, pull out just the human-readable message. Five minutes.

The auth issue turned out to be two things layered on top of each other. The first was a cookie security flag. When your browser stores a cookie, one of the settings you can attach to it is secure=True, which tells the browser to only ever send that cookie over an encrypted HTTPS connection and never over plain HTTP.² I had set mine to secure=False during local development, because my laptop runs everything over plain HTTP and I needed the cookie to work locally. I deployed to production — which runs over HTTPS — and never changed the flag. One line, wrong value, sitting there since the first push, quietly making the refresh token cookie transmittable over any connection type, including ones that aren't encrypted.

The second was bigger. My frontend's route protection only checked whether something existed in browser storage under the token key. It never verified that the something was real. To understand why that matters: localStorage is a small key-value store built into every browser — basically a sticky note your web app leaves on the user's computer.³ Anyone can write to it. Open DevTools on any website, type localStorage.setItem('token', 'banana') into the console, and you've written "banana" to that site's storage. My route protection was checking whether the sticky note existed, not whether what was written on it was a real, cryptographically signed token the backend had actually issued. A sticky note that says "banana" and one that says "valid JWT" look identical to a check that only asks "is there a sticky note." Open the console, type one line, set a fake value, and the entire protected dashboard would render. The backend correctly rejected the fake token the whole time, so no real data was ever exposed. But the frontend never asked. The fix was making the route protection actually call the backend before rendering anything protected, rather than trusting whatever happened to be written on the note.

The third thing turned out to be the most interesting one to find, and I introduced it myself while fixing the auth bypass.

Here's the setup: when a request fails because the access token has expired, my app automatically tries to get a new one by calling a /auth/refresh endpoint. This all happens silently in a piece of code called an axios interceptor — a layer that sits between every outgoing request and its response, intercepting failures before the rest of the app ever sees them. The interceptor catches a 401 (which means "not authorized"), makes a refresh call, gets a new token, and retries the original request. Clean, automatic, invisible to the user.

The problem: the refresh call itself goes through the exact same interceptor, since it's made using the same shared API client. So when I tested the fix with a completely fake token — one that would fail both the original request and the refresh attempt — here's what happened: the /logs/ request returned 401, the interceptor tried to refresh, the /auth/ refresh request also returned 401, and the interceptor saw another 401 and tried to refresh that too. But refreshPromise, the variable tracking the in-flight refresh, was already set because we were literally in the middle of creating it. So the interceptor did await refreshPromise... waiting on a promise that could only resolve once the thing currently running had already finished.

It was waiting for itself.⁴ The page spun forever with no error and no explanation, because nothing was ever going to resolve a promise that depended on its own completion. The fix was a single condition: if the failing request is the refresh endpoint itself, skip the retry logic entirely and just reject immediately. One line. But finding it required reading console logs carefully enough to notice that the interceptor was firing twice — once for /logs/ and once for /auth/refresh — and asking why the second one was trying to refresh at all.

The thing they didn't find

Here's where it got interesting. While I was already in the codebase tracing every route, I found something the comment hadn't mentioned at all.

A quick piece of background: when you define a database table using SQLAlchemy, the Python library I use to talk to PostgreSQL, you write a Python class describing what the table should look like. Then you run a command called create_all(), which tells SQLAlchemy to look at all those classes and create the corresponding tables in the database — but only if they don't already exist. It's a one-way door. It creates, it never alters. If a table already exists and you later add three new columns to the Python class, create_all() sees the existing table, decides it's already there, and moves on without touching it.⁵ Your new columns stay in the code forever and never make it to the actual database.

I had added three new columns to the users table during development — role, is_verified, and verification_token — and manually rebuilt my local database to pick them up. But the production database on Railway had been running since before those columns existed. create_all() looked at it, saw a users table, and did nothing. Every time a real stranger tried to register on the live site, the backend tried to write to columns that didn't exist, the database threw an error, and the whole registration silently failed — no useful error message, no obvious cause, just a broken form on a deployed app that had been working in my local environment the whole time.

Three bugs found from one comment. One more found just from looking closely. None of them were the hard parts.

What slips past is usually simpler than what doesn't

That last part is the thing I keep turning over. The hard parts of building HealthTrack — the JWT refresh token system, the database schema design, the rate limiting, the role-based access control — those got my full attention. I thought carefully about them. I read documentation. I tested them.

The bugs that actually broke production were none of those things. They were:

A False that should have been True. A database migration step I forgot to run. A frontend check that trusted a string without verifying what the string meant.

The pattern is almost embarrassing once you see it: you spend so much focused attention on the genuinely complex parts of what you're building that the simple finishing steps slip right past you. Changing the database schema required real skill and thought. Remembering to rebuild the production database afterward was just a step. A simple, obvious, last step that I didn't do, and it broke everything.

I think about deployment differently now. When you finally finish something after hours of building, deployment feels like the finish line. You push, you wait, you see it live, and that rush of relief makes it feel like you're done. But deployment isn't the finish line. It's the beginning of the part where real people can see it, which means it's the part that requires its own careful attention, its own checklist, its own moment of "did I actually think about whether this setting makes sense in a production environment and not just on my laptop?"

Nobody told me that. Or maybe someone did and I wasn't listening yet, because I hadn't felt it yet.

The part that's genuinely freaky

Somewhere out there, while I was making lattes or reading or trying to get eight hours of sleep, a stranger was opening my application in a browser I'd never know about, typing test inputs into my registration form, watching the network tab, checking what my cookies looked like, and quietly noting which things didn't behave the way they should have.

That's the internet. That's what live means. The moment something is deployed, it stops being yours alone — it becomes a thing that exists in the world, accessible to anyone with a browser and enough curiosity to look closely. Most people don't look closely. But some do. And they will find the False that should have been True.

I find this both deeply unsettling and genuinely useful to know. Unsettling because the comfortable bubble of "only I ever use this" is gone the moment you push to production, and it doesn't come back. Useful because the alternative, not knowing, is so much worse. A stranger who finds your bugs and tells you kindly is the best possible outcome. It's better than a stranger who finds them and says nothing. It's better than finding out much later, in a context where the stakes are higher.

The comment closed with a suggestion to go skating and enjoy the summer. I did, eventually. But first I rebuilt the production schema, tightened the cookie flag, fixed the frontend auth check, resolved the deadlock I introduced while fixing the other things, set up a real email verification flow for actual strangers, and wrote a full technical breakdown of every issue as a GitHub comment before closing the issue as resolved.

Deployment is part of building. I know that now in a way I didn't before, because I felt it, which is the only way any of this really sticks.

Footnotes

¹ HTTP status codes are standardized response codes servers send back to indicate what happened with a request. 4XX codes indicate client errors — 401 is "unauthorized," 403 is "forbidden," 422 is "unprocessable entity." MDN: HTTP response status codes

² The Secure cookie attribute restricts the cookie to HTTPS connections only, preventing it from being transmitted over unencrypted HTTP. MDN: Using HTTP cookies — Secure attribute

³ localStorage is a Web Storage API that lets websites store key-value pairs in the browser with no expiration date. Unlike cookies, localStorage is never automatically sent to the server — it's purely client-side. MDN: Window.localStorage

⁴ This is a form of deadlock — a situation where two or more operations are each waiting for the other to complete, so neither ever does. Wikipedia: Deadlock

⁵ This is the distinction between schema creation and schema migration. create_all() handles creation only. For altering existing tables in production, you'd normally use a migration tool like Alembic, which tracks schema changes over time and applies them incrementally. Alembic: database migrations for SQLAlchemy

Why Your Doctor Still Faxes Things, and What It Would Actually Take to Fix It

Zamira Dzhatdoyev — Mon, 29 Jun 2026 20:53:03 +0000

A physician in 2026 can still find it easier to fax a patient record than to share it electronically with a colleague across town.¹

That sentence is worth sitting with for a second, because it sounds like a joke and isn't one. Healthcare has spent the last few decades developing diagnostics, therapies, and procedures that would have sounded like science fiction a generation ago. And somewhere underneath all of that progress, a hospital's computer system frequently cannot simply hand a patient's chart to the hospital three blocks away. The reason why is a genuinely interesting infrastructure story, and the standard built to fix it is worth understanding.

The problem isn't that hospitals don't have computers

Nearly every hospital in the country has long since digitized. Close to 95 percent of hospitals and 90 percent of office-based physicians use some form of electronic health record system.² The data exists. It's stored, searchable, backed up, all the things you'd expect from modern software.

The problem is that "digitized" and "able to talk to each other" turned out to be two completely different achievements. Despite billions of dollars invested in electronic records and health information exchange programs, interoperability (the ability of different systems to actually exchange and use each other's data) remains one of healthcare's biggest operational bottlenecks.³ Only 55 percent of hospitals can even find a patient's information electronically from an outside organization, and just 40 percent of those can pull that information directly into their own system without someone manually re-entering it.⁴

That second number is the one that actually matters. Even when the data successfully crosses from one hospital's system to another, less than half the time can it just slot into place. The rest of the time, a human is retyping it.

It's worth picturing what that actually looks like in practice. Imagine two countries that both have excellent, modern postal services, fast trucks, reliable carriers, sturdy envelopes, but they use completely different addressing systems, different paper sizes, and different languages on the label. A letter can absolutely travel from one country to the other. It just can't be automatically sorted, read, or filed once it arrives, because nothing about its format makes sense on the receiving end. Someone has to manually translate it by hand before it's actually useful. That's roughly the state of most hospital-to-hospital data exchange. The delivery problem got solved decades ago. Nobody fully agreed on the label.

Why this isn't simply a technical oversight

It would be easy to assume nobody thought hospital software needed to talk to other hospital software, but that's not quite right either. Two genuinely structural obstacles are doing most of the damage.

The first is historical. Each hospital, over decades, picked its own electronic health record vendor, often years before any of today's standards existed, and built years of workflows, custom fields, and internal logic on top of whatever that vendor's system happened to support. Ripping that out and replacing it is enormously disruptive and expensive, so most hospitals simply don't, even when a better standard becomes available.⁵ It's the same reason nobody tears out a building's plumbing just because a better pipe material got invented after the building was already finished. The new material might genuinely be better. Replacing everything behind the walls is still a renovation nobody wants to live through.

The second is more subtle and arguably more interesting: even identifying that two records belong to the same person across two different systems is a real, unsolved-at-scale problem. Matching patient records accurately across and within different healthcare settings is one of the biggest barriers to real interoperability, separate from the question of whether the systems can technically transmit data to each other at all.⁶ A hospital across town might have you listed under a slightly different spelling of your name, an old address, a maiden name, or a different format for your date of birth, and there's no universal patient ID tying all of that together the way, say, a Social Security number ties together tax records. Two systems can be perfectly capable of exchanging data and still not be sure they're talking about the same human being. It's less like a broken phone line and more like two people trying to figure out if they went to the same wedding, except neither of them is allowed to just ask the obvious question, and the only clues they have are a slightly misspelled name and an address from six years ago.

What the old way of exchanging health data actually looked like

To understand why the fix is truly clever, it helps to see what it replaced.

The older HL7 standards, versions 2 and 3, are still running underneath most U.S. health systems today.⁷ HL7 version 2 moves information as pipe-delimited messages, meaning data fields are separated by literal vertical pipe characters in a flat block of text, a format that predates the modern web entirely and was never designed with something like a REST API or JSON in mind.⁷ Version 3 tried to formalize things further using a complex underlying reference model, but it became notoriously difficult to implement consistently, which meant different vendors interpreted and extended it in subtly incompatible ways.

Think of an HL7 v2 message like a grocery list scrawled on a single line of receipt paper: milk, comma, eggs, comma, bread, with no further structure beyond the order things happen to appear in. It works fine if you wrote it and you're the one reading it back. It works considerably worse the moment you hand that same scrap of paper to someone else and expect them to correctly understand which item was a quantity, which was a brand, and which was just a note to self, because nothing about the format tells them. Two systems could both technically read HL7 v2 and still disagree about what a given pipe-separated value actually meant in context, because the standard left enough room for interpretation that compatibility was attempted more than it was guaranteed.

So for years, the "standard" way for two health systems to exchange a patient's data was a message format roughly as old as fax itself in spirit, even when it was technically running over modern infrastructure.

The fix: treating health data like any other modern API

This is where FHIR comes in, pronounced like the word "fire," standing for Fast Healthcare Interoperability Resources.

The core idea is refreshingly simple once you see it: instead of one giant, rigid message format trying to represent an entire patient encounter at once, FHIR breaks healthcare data into small, modular building blocks called Resources, like Patient, Encounter, Observation, and MedicationRequest, each with a defined structure that any system implementing FHIR agrees to follow.⁸ A request can ask for just one piece, say, a patient's current medication list, rather than retrieving and parsing an entire monolithic document just to extract one fact buried inside it.⁹

This is the difference between mailing someone your entire filing cabinet because they asked for one receipt, versus handing them a labeled folder that contains exactly the receipt they wanted and nothing else. The filing cabinet technically contains the answer. The labeled folder is the answer. FHIR is healthcare data finally getting labeled folders instead of filing cabinets.

The genuinely clever part is what FHIR is built on top of. Rather than inventing another bespoke healthcare-only protocol the way earlier HL7 versions did, FHIR uses RESTful APIs, the same HTTP verbs, the same JSON formatting, the same web technology that powers an ordinary weather app or a ride-share app.¹⁰ A request to read a patient's record looks, structurally, almost identical to a request you'd send to any modern web API. This single decision matters more than it sounds like it should, because it means the enormous pool of developers who already know how to build and consume REST APIs can work on healthcare interoperability without learning an entirely separate, healthcare-specific way of moving data.¹¹ It's the engineering equivalent of designing a new currency that happens to use the exact coin slots every vending machine on the planet already has, instead of inventing a brand new slot shape and hoping every vending machine manufacturer eventually retools for it.

Authentication and patient consent get handled through a companion piece called SMART on FHIR, which layers standard OAuth 2.0, the same authorization protocol behind "log in with Google" buttons everywhere on the internet, onto the FHIR data layer.¹² A patient's phone app, a specialist's office, and a hospital's main system can all request access to specific FHIR resources, with the patient's consent enforced through familiar, modern authorization machinery rather than something healthcare-specific and unfamiliar to most engineers. You've already used the exact mechanism behind this, probably this week, every time you let some app log into your Google account instead of making a brand new password just for that one app.

Why this still doesn't fully solve the problem

Adoption of the actual API layer has moved remarkably fast for healthcare's usual pace. More than 95 percent of certified health IT developers had implemented the federally required patient access APIs by the end of 2022.¹³ By most measures, FHIR has won as the standard.

And yet only 43 percent of U.S. hospitals routinely meet the actual four-part definition of true interoperability, despite that near-universal technical certification.¹³ Having the API exposed and having the data genuinely, reliably, usefully flow between systems turned out to be two different milestones.

This gap makes more sense once you stop thinking of FHIR as a finished bridge and start thinking of it as a universally agreed-upon bolt size. Everyone now knows what size bolt to use. That doesn't mean every bridge has actually been built, or that the older bridges built decades ago with completely different bolts have been retrofitted to match. FHIR solves the format problem: two systems can now structurally understand each other's messages in a way HL7 v2 never reliably guaranteed. It does not, on its own, solve the patient-matching problem, the workflow problem, or the simple fact that countless hospitals are still running older systems that were never built around it in the first place.⁶

This is a pattern worth recognizing in any large legacy system, not just healthcare. A better standard arriving doesn't retroactively fix every system built before it existed. It just gives everyone building going forward a much better foundation to build on, while the slow, expensive work of migrating everything that came before continues in the background, often for decades.

Why this matters beyond the hospital

The actual cost of all of this isn't abstract. Poor interoperability drives duplicate testing, denials, and administrative waste across hospitals and physician practices.³ An analysis of cyberattacks on interoperable health record systems found the average hospital outage afterward lasted 24 days, at an average cost of roughly 10 million dollars per incident, partly because of how deeply intertwined and fragile these connections between systems can be once they exist at all.³

There's a real engineering lesson underneath all of this, one that applies just as much outside of healthcare. The hardest part of connecting two systems is rarely the wire format. It's agreeing on what a piece of data actually means, making sure both sides are confidently talking about the same real-world thing, and accepting that whatever standard you ship today will spend the next twenty years coexisting with everything that came before it. FHIR is a genuinely good answer to the first problem. The second and third are still, slowly, being solved one hospital at a time.

Footnotes

¹ On the persistence of fax-based record sharing despite decades of EHR investment. Medical Economics: The dirty secret — why your EHR still can't talk to other systems

² On EHR adoption rates among U.S. hospitals and physicians. Rhapsody: 4 Reasons Why EHR Interoperability Is a Mess

³ On the operational and financial costs of poor interoperability, including outage data after cyberattacks. CertifyHealth: Healthcare Interoperability Challenges & Practical Solutions

⁴ On the share of hospitals that can locate and actually integrate outside patient data. Certinal: Interoperability of Electronic Health Records

⁵ On the cost and disruption of replacing legacy EHR infrastructure. MyMedicalRecords: Healthcare Interoperability — Why Systems Can't Connect

⁶ On patient record matching as a distinct, unsolved obstacle separate from data format compatibility. Rhapsody: 4 Reasons Why EHR Interoperability Is a Mess

⁷ On HL7 v2's pipe-delimited message format and why FHIR was developed as its modern successor. Commure: What Is HL7 FHIR? A Practical Overview

⁸ On FHIR's modular Resource-based data model. Wikipedia: Fast Healthcare Interoperability Resources

⁹ On granular data retrieval as a specific advantage of FHIR's resource model over older document-based exchange. ONC: What Is HL7 FHIR? Fact Sheet

¹⁰ On FHIR's use of REST APIs and JSON, the same web technologies used outside healthcare. BGO Software: HL7 FHIR and APIs — The Full Interoperability Guide

¹¹ On FHIR tapping into the existing developer talent pool already familiar with REST and JSON from outside healthcare. Commure: What Is HL7 FHIR? A Practical Overview

¹² On SMART on FHIR and its use of OAuth 2.0 for authorization and patient consent. HL7: SMART App Launch Framework, Official Specification

¹³ On near-universal certified FHIR API adoption alongside the much lower rate of hospitals meeting true interoperability standards. Commure: What Is HL7 FHIR? A Practical Overview

Hideo Kojima Predicted the AI Crisis in 2001 and We Weren't Paying Attention

Zamira Dzhatdoyev — Fri, 26 Jun 2026 17:19:58 +0000

⚠️ Spoiler warning: this post spoils significant plot points from Metal Gear Solid 1, 2, 3, and 5. If you haven't played them and plan to, bookmark this and come back. You'll thank me.

I want to tell you about a video game that was released in 2001 and accidentally wrote the most accurate prediction of the 2020s that I have ever encountered in any medium.

Not a think piece. Not an academic paper. Not a technology forecast from a Silicon Valley futurist with a Substack. A video game. About a man in a box sneaking past guards.

The game is Metal Gear Solid 2: Sons of Liberty. The developer is Hideo Kojima. And if you haven't played it, or if you played it when it came out and forgot what it was actually about underneath all the cardboard boxes and codec calls, I need you to sit with me for a few minutes.

Because I finished it recently and had to put the controller down and just stare at the wall for a while.

First, some context on Kojima

Hideo Kojima is one of the most singular creative figures in the history of video games.¹ He makes games that are also movies that are also philosophy lectures that are also deeply weird personal obsessions dressed up as action thrillers. His games are famously long, famously strange, and famously full of moments that reach through the screen and grab you by the collar.

He's been doing this since the late 1980s. The Metal gear series spans decades, multiple consoles, and an increasingly elaborate mythology about genetics, warfare, identity, information, and what it means to be human in a world built by systems that don't care about you.

What strikes me, coming to these games now, is how much of what he was writing about as science fiction has quietly become science fact. Not in a "wow he predicted smartphones" trivia way. In a "this is genuinely unsettling" way.

The machine that reads you

Let's start with Metal Gear Solid 1, because it contains what might be the most quietly prophetic moment in gaming history and it's disguised as a boss fight.

You're fighting Psycho Mantis. He's a psychic. And to demonstrate his power, he does something no video game had ever done before: he reads your PlayStation memory card.²

Not metaphorically. Literally. The game accesses your save data and Mantis comments on what he finds — which other Konami games you've been playing, how much you've saved, what your habits reveal about you as a player. He knows you. Not your character. You.

Then, because he can read your mind through your controller, he makes your controller vibrate on the floor like a trick. And the only way to beat him is to physically unplug your controller from port one and plug it into port two — breaking the psychic link by changing the input channel.

In 1998, this was a wild gimmick. A cool party trick that made everyone who experienced it put the controller down and say "wait, WHAT."

In 2026, it's a description of how every algorithm you interact with actually works.

Your data is being read. Your habits, your history, your patterns across platforms — all of it is being analyzed to predict your behavior and influence your actions. The only difference between Psycho Mantis and a recommendation algorithm is that Mantis was honest about what he was doing. He told you he was reading you. He let you fight back.

The algorithm doesn't tell you. And there's no second controller port to plug into.

The simulation you didn't know you were in

Metal Gear Solid 2 is where Kojima stopped hinting and started screaming.

The game opens as a direct sequel to MGS1: you're playing as Solid Snake, the iconic protagonist, on a mission to infiltrate a tanker. It feels familiar. It feels like more of the same. And then, about two hours in, the rug gets pulled.

You're not Snake anymore. You're Raiden — a new character, a rookie, someone you've never met. And as the game progresses and the layers peel back, a horrifying truth emerges: Raiden's entire mission has been a simulation. A carefully constructed scenario designed to create a soldier, to test whether the perfect operative could be produced through controled experience rather than lived reality.

Raiden wasn't playing the game. The game was playing Raiden.

The entity behind this is the Patriots — a shadowy AI collective that has been controlling the flow of information in human society for decades.³ Not with guns or bombs. With data. With narrative. With the careful curation of what people know, what they believe, and what they think they chose freely.

The Patriots don't control people by force. They control the environment those people live in. They decide what rises and what disappears. They shape consensus. They manufacture reality.

I played this in 2025. I had just spent an afternoon scrolling through a social media feed that seemed specifically designed to make me feel a particular way about particular things. I had just read three different accounts of the same news event that somehow described completely different realities. I had just watched an Ai generate a convincing video of something that never happened.

Kojima wrote this in 2001. About a fictional AI. About the future.

The future was not fictional.

The moment where the game broke itself

Here's where it gets personal.

Near the end of MGS2, the game starts to come apart. Not because of a bug, but on purpose. The interface begins to malfunction in ways that feel wrong — your codec calls become fragmented and strange, characters say things that don't make sense, the AI colonel who has been guiding you through the whole game begins to glitch and deliver fractured, disturbing messages that bleed between reality and static.

And then the game lies to you. It tells you that you died. It puts up a 'Game Over' screen. But instead of restarting, it keeps going, your gameplay miniaturized into a corner of the screen, a spectator view of your own death, the game continuing without your permission.⁴

The boundary between the player and the game, between what's real and what's constructed, dissolves completely. You're not watching Raiden question his reality. You are questioning yours. The disorientation isn't described. It's inflicted.

I remember not being able to fully process what was happening to the screen. I remember genuinely not knowing whether I was supposed to keep playing or whether something had gone wrong. That confusion was the point. Kojima made you feel, in your own body, what it feels like when the systems you trusted to tell you what's real start giving you contradictory information.

That feeling has a name now. We just call it being online.

The speech

At the end of MGS2, the Patriots AI delivers a monologue.

I'm not going to reproduce it here — look it up, it's worth reading in full⁵ — but I want to tell you what it's about, because what it's about is everything.

It's about information. Specifically, what happens to human thought and culture when the amount of information available exceeds any individual's ability to process it. It describes a world where the sheer volume of data — the endless proliferation of voices, opinions, content, noise — makes genuine knowledge impossible. Where people can no longer distinguish signal from static. Where the solution, from the perspective of those who want control, is not to suppress information but to flood the zone with so much of it that people give up trying to find truth and simply accept whatever narrative is the loudest.

It describes, with eerie precision, the information ecosystem of the mid-2020s.

This speech was written before social media existed. Before smartphones. Before the algorithm. Before "fake news" was a phrase anyone used. Before AI could generate convincing text and images and video at scale.

Kojima saw it coming not because he had access to secret information but because he followed the logic. He asked: if information becomes the primary currency of power, what does power do with it? And he answered that question twenty years before the rest of us had to live inside the answer.

What MGS3 and 5 add to the picture

Metal Gear Solid 3 is a prequel set in the Cold War, and its technological anxieties are different — less about AI, more about the human cost of loyalty to systems that don't deserve it.⁶ The Philosophers, the predecessor to the Patriots, are a shadow organization controlling geopolitics from behind the scenes. The game asks: what does it do to a person to serve a system that uses them as a tool and discards them when they're no longer useful?

That question hasn't aged a day.

Metal Gear Solid 5 takes a different angle entirely — its central villain weaponizes language itself.⁷ The premise is that a pathogen targets speakers of specific languages, effectively using linguistic identity as a vector for biological warfare. The game is about how deeply identity is encoded in the systems we use to communicate, and what it means to have that stripped away.

In 2026, we are actively watching AI reshape language — generating text, translating, summarizing, optimizing for engagement — and having real conversations about what that does to meaning, to culture, to the way ideas travel between people. Kojima was already there.

Why this matters beyond the games

I'm a CS student. I build software. I think about systems, how they work, what they optimize for, what they do to the people who interact with them.

Playing these games as someone who understands how algorithms work, how data is collected and used, how recommendation systems shape behavior, how AI generates content... it hits differently than it would have hit a casual player in 2001.

Because Kojima wasn't just telling a story. He was building a model: A model of what happens when systems become sophisticated enough to shape human reality rather than just respond to it. A model of what power looks like when it operates through information rather than force.

That model turned out to be correct.

The scary thing isn't that he predicted the future. Lots of science fiction makes lucky guesses. The scary thing is that he understood the underlying logic well enough that the prediction was almost inevitable. That anyone following the thread of "what happens when information becomes the primary instrument of control" far enough would end up in the same place he did.

We're living in that place now. We just got here after him.

Footnotes

¹Hideo Kojima founded Kojima Productions and is best known for the Metal Gear series, which he created in 1987. He is widely regarded as one of the most auteur-driven figures in video game development. Wikipedia: Hideo Kojima

²The Psycho Mantis boss fight in Metal Gear Solid (1998) is widely cited as one of the most innovative fourth-wall breaks in gaming history. Mantis reads the player's memory card and commments on save data from other Konami games. Wikipedia: Psycho Mantis

³The Patriots (also known as the La-li-lu-le-lo) are a secret AI collective introduced in Metal Gear Solid 2 as the primary antagonists controlling global information flow. Metal Gear Wiki: The Patriots

⁴The Colonel AI's breakdown sequences in MGS2 are a deliberate narrative device in which the game's own interface becomes unreliable, forcing the player to experience Raiden's psychological destabilization firsthand. MGS2's fake "Fission Mailed" screen | Metal Gear Wiki: Roy Campbell (AI)

⁵ The Patriots' ending monologue from MGS2 can be watched in full on YouTube. An annotated breakdown is also available at junkerhq.net. YouTube: Colonel AI speech · junkerhq.net: Ending analysis

⁶Metal Gear Solid 3: Snake Eater (2004) is set in 1964 during the Cold War and centers on themes of loyalty, sacrifice, and the human cost of serving institutional power. Wikipedia: Metal Gear Solid 3

⁷Metal Gear Solid V: The Phantom Pain (2015) features a primary antagonist whose plan involves a pathogen targeting specific language speakers, exploring themes of linguistic identity and cultural erasure. Wikipedia: Metal Gear Solid V

New Jersey's Traffic Lights Are Solving a Harder Problem Than Most Software Engineers Ever Touch

Zamira Dzhatdoyev — Mon, 22 Jun 2026 20:08:41 +0000

New Jersey drivers complain about traffic the way other people complain about weather: constantly, specifically, and with the quiet assumption that nobody outside the state could possibly understand how bad it really is. This summer gives the state a fresh and very public excuse, since MetLife Stadium, temporarily renamed New York New Jersey Stadium because FIFA doesn't allow sponsor names anywhere near the World Cup, is hosting eight matches over six weeks.¹ Officials are planning to move more than 78,000 spectators per match through the Meadowlands using a coordinated network of shuttle buses, rail service, and rideshare drop-offs, with no general parking allowed at the stadium at all.²

Underneath all the complaining about Jersey traffic specifically is a genuinely hard, genuinely interesting computer science problem, one that's been quietly evolving for over a century, and it's worth taking seriously for a second before going back to complaining about it.

The problem existed before the technology did

Traffic lights weren't invented because someone thought intersections needed decoration. They were invented because cities were, in the words of one 1920s report, "unbearable, unendurable, uncontrollable."³ By the early 1920s automobiles had started outnumbering horse-drawn wagons in major cities, and the resulting mix of cars, streetcars, pedestrians, and horses all fighting for the same intersections at the same time produced exactly the chaos you'd expect.⁴

The earliest fixes were entirely human. A traffic officer stood in a booth or a tower and manually flipped switches or waved semaphore arms.³ It worked, sort of, but it scaled terribly, since it meant a dedicated person at every busy corner in a growing city, all day, making judgment calls under pressure with no way to coordinate with the officer at the next intersection over.

The shift toward automation came from a Detroit police officer named William Potts, who in 1920 built the first four-way, three-color traffic signal, adding the amber light specifically because he was frustrated that police at different intersections couldn't change their lights at exactly the same moment.⁵ He attached a timer to coordinate it. The economic case for doing this was immediate and enormous: automating signal timing in New York City let the department reassign all but 500 of its 6,000 traffic officers, saving the city an estimated $12.5 million.⁵

That's the first version of the core tradeoff this whole post is actually about. A human directing traffic can react to what's actually happening in front of them, but doesn't scale. A timer scales effortlessly across an entire city, but has no idea what's actually happening in front of it. Nearly every advance in traffic engineering since 1920 has been an attempt to get the responsiveness of the first approach without losing the scalability of the second.

Why a fixed timer alone was never going to be enough

For decades, that's basically all traffic lights were: fixed interval timers, running the same preset schedule regardless of what traffic actually looked like at any given moment.⁶ This is precisely why it's possible to sit at a red light at 2am with zero cross traffic in sight and just wait anyway. The signal isn't responding to reality. It's running a script written in advance, based on average conditions, applied uniformly whether it's the dead of night or the exact moment 78,000 World Cup fans are all trying to leave the Meadowlands at once.

The first real attempt to make signals actually sense the world came in the 1950s. In 1952, Denver installed a single computer that controlled 120 traffic lights citywide, fed by six pressure-sensitive detectors that measured inbound and outbound traffic, with the entire control room housed in the basement of the City and County Building.⁷ By the 1960s, cities like Toronto were running even more advanced detection across 159 signals through ordinary telephone lines.⁷ The 1970s introduced vehicle sensors directly into the pavement itself, which finally let signals adjust their timing based on whether anyone was actually there, rather than running the exact same plan at 3am and 3pm alike.⁸

What it actually takes to make a light "smart" today

Modern adaptive systems are the direct descendants of that 1950s Denver experiment, just dramatically more capable. Sensors at intersections and along corridors continuously monitor traffic volume, speed, occupancy, and queue length, using inductive loops embedded in the pavement, video detection cameras, radar, or data pulled directly from connected vehicles.⁹ An adaptive system detects a heavy queue building in one direction, extends the green light for that approach, and shortens it for the less busy directions, continuously, rather than running the same fixed plan all day regardless of what's actually happening.⁹

That alone is already a meaningfully harder problem than it sounds like, because it means weighing competing demands in real time. Extend the green for the backed-up direction too long, and the side street that was previously moving fine now backs up instead. Every adjustment at one intersection changes the conditions feeding into the next one down the road, which is exactly the kind of problem that gets harder, not easier, as you add more intersections to coordinate.

The part that's genuinely elegant: green waves

Here's the concept that made me actually respect traffic engineering as a discipline, and it's older than you'd think. New York City pioneered synchronized traffic lights as early as the 1920s, building systems that coordinated signal timing across multiple intersections at once so vehicles could move smoothly along major streets without stopping at every block.¹⁰

When a series of intersections coordinate their timing so a driver moving at the expected speed hits green light after green light continuously, it's called a green wave.¹¹ The signal phases and periods across multiple lights get chosen specifically so that a stream of traffic can flow continuously through several intersections in a row, typically along one or two directions.¹¹

This only works under certain conditions. Green waves are most effective when traffic velocity is relatively constant, and when most traffic is heading in the same direction at the same time, which is exactly why a perfectly synchronized green wave during a normal Tuesday afternoon commute can completely fall apart the moment something abnormal happens, like, for instance, tens of thousands of soccer fans converging on a single stadium from every direction at once. There are real mathematical constraints on achieving full coordination across all directions simultaneously, which means a system tuned for smooth north-south flow during rush hour has to make tradeoffs that get exposed the instant traffic patterns change.¹¹

This is, fundamentally, a distributed coordination problem. No single intersection has full visibility into the entire network's state. Each one makes local decisions based on local sensor data, while ideally still contributing to a coherent pattern across the whole corridor, which sounds a lot like the kind of distributed systems challenge that shows up constantly in software, just with the added twist that a wrong decision here doesn't throw an error, it throws an extra fifteen minutes onto someone's commute.

Why this summer is the system's actual stress test

Officials are well aware that this particular stress test is coming. The coordination plan for World Cup matchdays spans NJ Transit, the Port Authority, the MTA, the New Jersey Department of Transportation, the New Jersey Turnpike Authority, and Amtrak, all working together to move spectators in and out of a stadium that explicitly will not allow general parking on its own property.² Rail service to the stadium will run on a matchday-only schedule, requiring fans to transfer through Secaucus Junction, while regular commuters not attending matches get rerouted through entirely different paths just to avoid colliding with the surge.¹²

It's worth pointing out that the actual cost of moving all these people has become its own minor political dispute, with the state pushing back on FIFA over who foots a roughly $48 million transportation bill for the event.² Whatever gets decided, the underlying engineering challenge doesn't change: a transportation network tuned for ordinary commuting patterns has to absorb eight days, spread across six weeks, of wildly atypical demand, concentrated at one location, arriving and leaving within tight windows around kickoff.¹²

Modern adaptive traffic systems are explicitly designed to flex with real-time conditions instead of running a fixed script, which is exactly the kind of flexibility a one-off mass event actually needs.⁶ But there's a meaningful difference between handling the normal daily variance of a commute and handling a sudden, massive, geographically concentrated spike that doesn't match any pattern the system has tuned itself against before. Sensors and adaptive algorithms can react to what they're currently seeing, but a green wave optimized for typical traffic flow doesn't automatically know what to do when typical stops applying for one Saturday afternoon, eight separate times, between June and July.

Why New Jersey drivers are right to complain, just maybe not for the reason they think

The instinct to blame "Jersey traffic" specifically, as if the state has uniquely bad luck or uniquely bad drivers, misses the more interesting truth: this is a hard coordination problem everywhere, with a hundred-year history of incremental fixes, each one solving the limitation of the last one while introducing a new one. A timer fixed the scaling problem an officer couldn't solve. A sensor fixed the responsiveness problem a timer couldn't solve. A green wave fixed the single-intersection myopia a lone sensor couldn't solve. And a sudden, massive, atypical event is exactly the failure mode none of those previous fixes were built to anticipate.

New Jersey just happens to be running one of the more demanding live versions of that century-long problem this summer, with one of the densest, most interconnected transit and roadway systems in the country trying to absorb an unusually concentrated load. It is, in the end, the same basic problem any distributed system runs into under unexpected load: a network that's well-tuned for its normal traffic pattern gets stress-tested the moment something abnormal and large arrives all at once, and the seams show up exactly where the system wasn't designed to flex. New Jersey is about to find out, eight times, over six weeks, exactly where those seams are.

Footnotes

¹ On MetLife Stadium being temporarily renamed for the 2026 World Cup and the match schedule. ABC7 New York: Take a tour of New York New Jersey Stadium

² On the regional mobility plan, spectator volume, and the transportation cost dispute with FIFA. ROI-NJ: World Cup Host Committee and NJ Transit Announce Regional Stadium Mobility Plan

³ On the urban chaos that prompted the invention of automated traffic signals in the 1920s. OPTraffic: The Evolution of USA Automatic Traffic Light Signal Timing

⁴ On the rise of automobile traffic in the 1920s and the resulting safety problems at intersections. EBSCO Research Starters: Traffic Signals Invented

⁵ On William Potts's 1920 four-way, three-color traffic signal and its economic impact on New York City's police department. Wikipedia: History of Traffic Lights

⁶ On the limitations of fixed-time traffic signal systems compared to adaptive ones. Omnisight: What Is Adaptive Signal Control and How Does It Improve Traffic Flow

⁷ On the 1952 Denver computerized traffic control system and Toronto's 1967 telephone-line-based signal network. Wikipedia: History of Traffic Lights

⁸ On the introduction of vehicle sensors in the 1970s, enabling real-time signal adjustment. OPTraffic: The Evolution of USA Traffic Lights in the Past Century

⁹ On the sensors and real-time decision-making behind adaptive traffic signal systems. Eltec: Adaptive Traffic Signal Control Systems Explained

¹⁰ On New York City's early synchronization of traffic signals across multiple intersections in the 1920s. OPTraffic: The Evolution of USA Automatic Traffic Light Signal Timing

¹¹ On the concept of green waves and the mathematical constraints on coordinating traffic across multiple intersections. arXiv: Self-Organization in Traffic Lights

¹² On the specific matchday rail service adjustments and rerouting for World Cup 2026 at MetLife Stadium. NJ Transit World Cup: Commuters

My Cat Is Event-Driven and Honestly She's Better Architected Than Most Software I've Used

Zamira Dzhatdoyev — Mon, 22 Jun 2026 19:57:46 +0000

I want to introduce you to Nami.

Nami is a shorthair cat. She is loud, opinionated, aggressively social, and has the prey detection capabilities of something that should not be living in a house catching houseflies mid-air with her bare paws like it's nothing. She still suckles on blankets when she makes biscuits, which is the single most grossly adorable thing I have ever witnessed another living creature do.

She also, I have come to realize, is a perfect implementation of event-driven architecture.

I did not plan to learn a computer science concept from my cat. But here we are.

What event-driven architecture actually is

Most software runs on a schedule or in a loop. Do this, then do this, then check if this happened, then do this again. It's predictable. It's sequential. It does things whether or not anything interesting is happening.

Event-driven architecture is different.¹ Instead of running continuously on a schedule, an event-driven system sits idle until something happens — a trigger, a signal, an event — and then responds to it. The system doesn't decide when to act. The world decides, and the system reacts.

The classic example is a user interface. A button doesn't do anything until you click it. The click is the event. The function that runs when you click is the handler. Nothing happens without the trigger.

Nami has been doing this her entire life and frankly she's very good at it.

Nami's event handlers, documented

Event: front door opens

This one has multiple response layers and I want to walk you through all of them because the engineering here is genuinely impressive.

Layer one: Nami detects the door opening from anywhere in the house. I do not know how. The door makes a sound but she responds before the sound finishes. Some kind of pre-emptive interrupt handler.²

Layer two: she sprints toward the door at full speed, because outside is out there and outside is the dream and every open door is a potential portal to the outside and she will not miss it.

Layer three — and this is the part that gets me — if the door closes before she makes it, she does not give up. She sits by the door. She cries at the door. And then, if nobody responds to the crying, she leaves the door, finds a human, makes prolonged eye contact, and physically leads them back to the door.

She implemented a callback function.³ She registered her intent with the door, got no response, and passed the request up the chain to a human who has door-opening permissions. This is not instinct. This is resource escalation logic.

The truly beautiful part is what happens when she actually gets outside. She goes out, looks around, realizes nobody is out there to play with her, and immediately starts crying for you to come outside too. She fought her way through three layers of door-access logic to get outside and her first move is to file a complaint that the outside doesn't have enough people in it.
Honestly same.

Event: fly detected

Handler activates immediately. No deliberation. No warmup. Nami goes from zero to full predator in the time it takes the fly to realize it made a terrible mistake.

She catches them mid-air. With her paws. While they're flying. I have watched her jump and close her paw around a housefly in motion and I genuinely do not understand the physics of it. Her reaction time is faster than mine by a margin that is embarrassing to admit.

In software terms this is a low-latency interrupt handler with extremely tight response time requirements.⁴ No queuing. No batching. Immediate execution. The fly is the event. The catch is the response. The entire pipeline from detection to completion takes approximately one second.

I have written API endpoints slower than Nami catches flies. This is not a complaint about Nami.

Event: human wakes up / comes home / walks past after a nap reset

This one triggers the signature Nami response: a long, drawn-out, entirely sincere MEEEOOOOOWWWW delivered at a volume that suggests she has not seen you in years and was beginning to give up hope.

She also does a little stretch and flop when she wakes up. Like she's rebooting. Running her startup sequence. Checking all systems before resuming normal operation. The meowing is the startup chime.

What I love about this handler is that it's stateful. Nami tracks how recently she's been pet and socializes accordingly. A fresh nap resets her excitement-to-be-pet meter back to maximum. Every human who walks by after a nap gets the full MEEEOOOOOWWWW experience regardless of how recently she saw them, because from her perspective the nap was a hard reset and the world is new again.

This is exactly how a cache expiry works.⁵ Time passes, state is cleared, the next request is treated as fresh. Nami's affection has a TTL and it resets on sleep.

Event: it is time to come inside

Nami's error handling is where the architecture gets interesting.

When called inside, Nami does not come inside. Nami initiates evasion protocol. She finds ways to be just far enough away that you can't reach her. She looks directly at you and takes one step sideways. She discovers suddenly that there is a very interesting smell over there, no, over there, no actually over here.

When you finally pick her up — which you have to do, physically, because she has decided that voluntary re-entry is not something she offers — she makes a sound.

The only way I can describe this sound is: Yoshi's death sound effect from Mario.⁶ "Owowowowowww!!!" Long. Mournful. Betrayed. Like she wasn't just trying to avoid you for five minutes. Like this is a great injustice being visited upon her specifically.

In software terms this is an unhandled exception that throws the loudest possible error before gracefully shutting down.⁷ She doesn't crash. She complains extensively and then accepts the outcome. Honestly better error handling than a lot of software I've used.

The blanket thing

This one doesn't fit neatly into the event-driven framework and I want to include it anyway because it's important.

When Nami is comfortable and happy she makes biscuits on soft fabric — kneading with her paws, purring, and suckles on the blanket like she did with her mom as a kitten, because soft fabric is comfort and she never fully unlearned it. What a big baby.

There's no computer science parallel here. It's just a small creature doing what makes her feel safe, carrying something tender from her earliest days, and being completely unbothered about it.

I find that more moving than I expected to when I started writing a blog post about event-driven architecture.

What Nami actually taught me

The thing about event-driven systems is that they're responsive in a way that scheduled systems aren't. They don't waste resources doing things when nothing is happening. They don't miss things because they weren't checking at the right moment. They react to the world as it actually is, not as they expected it to be.

Nami doesn't plan her day. She responds to it. Fly appears, she catches it. Door opens, she runs. Human walks by, she announces herself. Blanket is soft, she makes biscuits. The world sends events and she handles them, immediately, with her whole self, every time.

There's something kind of beautiful about that actually. No overhead. No unnecessary processing. Just presence, and response, and a very loud meow to let you know she's paying attention.

She's sitting next to me right now. Not on me — she's a next-to person, not an on-top person, which I respect — just close enough to remind me she's there.

Event: human is typing.

Handler: sit adjacent. Purr occasionally. Supervise.

She's doing great.

Footnotes

¹Event-driven architecture is a software design pattern where the flow of a program is determined by events such as user actions, sensor outputs, or messages from other programs. Wikipedia: Event-driven architecture

²In computing, an interrupt is a signal that temporarily halts the current process to handle a higher-priority event. Hardware interrupts respond faster than software polling — similar to how Nami responds before the sound of the door even finishes. Wikipedia: Interrupt

³A callback function is a function passed as an argument to another function, to be executed once a condition is met or an event occurs. Nami escalating from "cry at door" to "go get human" is a textbook callback chain. MDN: Callback function

⁴Low-latency systems are designed to minimize the delay between an event occurring and a response being produced. High-frequency trading systems, real-time gaming, and apparently Nami's fly-catching reflex all operate in this category. Wikipedia: Latency (engineering)

⁵TTL (Time To Live) is a value that determines how long a piece of data is considered valid before it expires and must be refreshed. Nami's affection cache has a TTL of approximately one nap. Wikipedia: Time to live

⁶ If you've never heard it, the sound is worth experiencing for yourself. YouTube: Yoshi death sound effect

⁷Exception handling is the process of responding to unexpected conditions in a program. Good exception handling communicates the error clearly and recovers gracefully. Nami's Yoshi sound followed by resigned compliance is, architecturally speaking, exemplary. Wikipedia: Exception handling

Project Janus: The Most Interesting Infrastructure Project You've Never Heard Of

Zamira Dzhatdoyev — Fri, 19 Jun 2026 00:53:29 +0000

Let me set the scene.

It's late. I'm a CS student at NJIT, I'm planning my move for after graduation, and I'm doing what any reasonable person does when they should be sleeping — Googling "cool tech companies in Philly."

Most of what comes up is what you'd expect. Healthcare startups. Fintech firms. The usual suspects.
And then: Comcast.

My first instinct, I'll be honest, was to scroll past it. Comcast. The cable company. The one with the customer service memes. The one your parents call to yell at every few months. That Comcast.

But something made me click. And two hours later I was still reading, genuinely kind of losing my mind, because it turns out Comcast is doing something called Project Janus that I cannot stop thinking about.

So I'm going to try to explain it to you. Not in a dry technical way. In a "okay wait this is actually insane" way. Because that's how I experienced it.

First, some background on how the internet actually moves

When you load this blog post, your data doesn't teleport from a server to your eyeballs. It travels as tiny packets — little chunks of data — across a network of physical devices that pass them along like a relay race.¹

The most important devices in this relay race are called routers. A router's job is simple in concept and nightmarish in practice: look at every packet that arrives, read the address on it, and decide which direction to send it next.

Think of a router like a really fast postal worker standing at a fork in the road, reading the address on every envelope and throwing it down the right path. Now give that postal worker about a billion envelopes per second. That's closer to the reality.

For decades, the routers doing this work were specialized hardware boxes. Expensive ones. Made by companies like Cisco and Juniper², costing hundreds of thousands of dollars each, running proprietary software that only the manufacturer fully understood.

If Comcast wanted to change how their network behaved — say, reroute traffic around a congested area — they basically had to ask Cisco nicely and wait. They were renting the brain of their own network from a vendor. Imagine buying a car but the steering wheel is locked and only the dealership has the key. That's what this felt like.

Now imagine you're Comcast

You have a network that reaches over 63 million locations across the United States.³ You have giant facilities called network hubs scattered around the country — essentially massive rooms full of these expensive proprietary boxes, all humming away, routing the internet for tens of millions of people.

And then streaming happens. And then 4K happens. And then everyone starts working from home simultaneously. And then Peacock streams an NFL playoff game that becomes the largest live streaming event in internet history at that time.⁴

Your network is getting absolutely cooked by traffic volumes nobody predicted. And your options for dealing with it are: spend a fortune on more proprietary hardware, wait for your vendor to release new firmware, or... think differently.

Enter Project Janus

Here's the big idea, and I promise it's simpler than it sounds.

What if you separated the "thinking" part of a router from the "moving packets" part?

The thinking part — deciding where to send traffic, managing the network map, handling failures — is just software. It doesn't need to run on a $500,000 Cisco box. It could run on a regular server. Or in the cloud. On hardware that costs a fraction of the price and that Comcast's own engineers can modify freely.

The moving packets part — physically receiving data and forwarding it at high speed — does need fast hardware, but it doesn't need to be proprietary. Cheap commodity "white box" switches⁵ can do it just as well if you write the right software to control them.

It's like realizing that the expensive brain surgeon you've been paying doesn't actually need a custom-built operating table from the same manufacturer as the scalpel. Any table works. The expensive part is the surgeon — and in this metaphor, Comcast is training their own surgeons.

This idea has a name: software-defined networking. And Project Janus is Comcast's implementation of it, applied to the core of their entire national network.⁶

They're ripping out the proprietary boxes. Replacing them with commodity hardware running software that Comcast engineers wrote themselves. And moving the "brain" of the network to cloud platforms where it can be updated, scaled, and fixed like any other piece of software.

But wait, it gets cooler

Because the network is now software, you can wire it up with sensors everywhere. Every link, every router, every traffic flow generates real-time data — latency, packet loss, utilization, anomalies.

Feed that data into machine learning models and suddenly your network can detect problems before customers notice them. Reroute traffic automatically when a link starts degrading. Fix itself without a human having to drive to a facility at 3am wondering why half a city lost internet.⁷

Comcast called this "AI-powered self-healing network functions" which sounds like marketing speak until you realize it's just what happens when you combine good telemetry with ML and give it control over real infrastructure. The network watches itself and fixes itself. That's not a press release buzzword. That's genuinely interesting engineering.

Think of it like a self-driving car, but instead of navigating roads it's navigating internet traffic — and instead of occasionally missing a turn, a mistake means millions of people lose connectivity simultaneously. The stakes are just slightly higher.

Why I can't stop thinking about this

I study computer science. I've built web apps, trained ML models, written data pipelines. But there's something about infrastructure at this scale that hits differently.

The engineers working on Janus are writing software that routes the American internet. Their code runs on hardware in facilities across the country, making decisions billions of times per second, for tens of millions of people who have absolutely no idea it exists. When it works, nobody notices. When it breaks, it's national news.

That's the kind of engineering that doesn't show up in tech Twitter discourse. It's not a new app. It's not an AI chatbot. It's not a faster way to order food. It's the invisible foundation that everything else runs on top of.

And a company most people associate with hold music and modem rental fees is doing some of the most interesting work in this space anywhere in the world.

So yeah. Comcast. That Comcast.

I get it now.

Footnotes

¹This is a simplified description of packet switching, the fundamental technology underlying the modern internet. Wikipedia: Packet switching

²Cisco and Juniper Networks are the dominant vendors in enterprise and carrier-grade networking hardware. Cisco | Juniper Networks

³Comcast Q3 2025 earnings report — network footprint figures. Comcast Investor Relations

⁴The 2024 NFL Wild Card game between the Kansas City Chiefs and Miami Dolphins, streamed exclusively on Peacock, broke records for the largest live streaming event in US internet history at the time. Comcast press release

⁵ "White box" switches are generic, vendor-neutral network hardware that can run open-source or custom network operating systems instead of proprietary vendor software. TechTarget: White box networking explained

⁶Comcast announced Project Janus in September 2024, launching initial trials in Atlanta. Comcast press release — Project Janus

⁷Comcast's description of Janus's self-healing capabilities comes from their official announcement. Source

The Morning Rush is a Distributed System (And Other Things I Think About While Steaming Milk)

Zamira Dzhatdoyev — Wed, 17 Jun 2026 14:45:36 +0000

There is a moment that happens maybe twenty minutes into a busy morning rush at a good coffee shop.
It doesn't announce itself. One second you're scrambling — tickets are piling up, someone needs change, the espresso machine needs a portafilter swap and nobody's free to do it. And then something shifts. The chaos doesn't go away but it becomes organized chaos. Everyone knows where to be. Nobody's talking. Nobody's assigning tasks. Things are just... happening. Drinks are moving. The line is shrinking.

I've been a barista long enough to recognize this moment when it arrives. I've also been a CS student long enough to recognize what it actually is.

It's a distributed system coming online.

Let me back up

I used to work at a bigger chain. High volume, high speed, mobile orders dominating the queue before the first customer even walked through the door. Everything optimized for throughput. It was efficient in a clinical sort of way.

Now I work at a local cafe. We make our syrups in house. The space is homey. Regulars know our names. The vibe is completely different — but the morning rush is still a morning rush, and the problem it poses is the same problem it poses everywhere:
How do you coordinate multiple people, multiple tasks, multiple queues of work, under time pressure, without stopping to have a meeting about it?

You don't have time to stop and assign roles. You don't have time to say "you take register, you pull shots, you steam milk, you run food." The line doesn't wait for your org chart.

So you don't make one.

How it actually works

There's no formal system. Nobody wrote it down. But every experienced barista knows it implicitly, the same way experienced engineers know certain patterns without having to look them up.

Someone is on the bar making drinks. In our shop that person is effectively the primary node — the one whose output rate determines everything else. Drinks don't leave without them. So when they need something, that need gets heard first. If they call for more oat milk, someone gets oat milk. If the espresso shots aren't pulled, someone pulls them. The bar barista doesn't have to manage the team — they just have to communicate what they need, and the team routes around it.

Everyone else is filling gaps. Someone steps away from register to grab cups from the back. In the half second they're gone, whoever is closest drifts toward the register naturally, without being asked, because there are customers and the register needs to be staffed. The person returns, sees the register covered, moves to wherever the next gap is. So on and so on.

An important distinction is that it's not choreography. It's more like... each person is running a simple loop. Look around. Find the highest priority uncovered need. Cover it. Repeat.¹

If you've taken a distributed systems course, this might sound familiar.

What this actually is

In computer science, a distributed system is a network of independent nodes that coordinate to accomplish a shared goal without any single point of control.² The interesting thing about distributed systems is that they're hard to design well precisely because there's no central coordinator telling everyone what to do. Each node has to make local decisions based on local information and still produce globally correct behavior.

A well-run coffee bar during a rush is solving exactly this problem. Each barista is a node. The shared goal is drinks moving out and customers moving through. There's no central coordinator — or rather, the bar barista plays a soft coordinator role not by issuing commands but by broadcasting state ("I need shots," "I'm out of cups") that other nodes can act on.

The way tasks get assigned isn't top-down. It's emergent. Each person observes the system state and responds to it. The result, when everyone is experienced and locked in, looks almost magical from the outside — this smooth, flowing, self-organizing machine that appears to run itself.

Distributed systems researchers would call this eventual consistency with local decision-making.³ I call it a really good Saturday morning shift.

The flow state thing

There's another computer science concept hiding in the morning rush and it's less academic but maybe more universally recognizable.
When you're locked in — really locked in, moving fast, not thinking about individual actions just executing them — you're in a flow state.⁴ Psychologists define it as a mental state of complete absorption where the challenge of a task matches your skill level precisely enough that you're fully engaged but not overwhelmed.

Baristas know this feeling. So do programmers. It's the same feeling.

In both cases it requires a certain kind of repetition; not mindless repetition, but skilled repetition. Your hands know what to do. Your brain is freed up to monitor the system, anticipate the next need, catch problems before they become crises. You're not thinking about how to steam milk while steaming milk. You're thinking about which drink needs to go out next and whether the shots for the one after that are ready.

The best coding sessions feel identical to me. My fingers know the syntax. I'm not thinking about how to write a for loop. I'm thinking about the architecture, the edge cases, the thing three steps ahead. The mechanical stuff happens below conscious thought.
Getting into that state intentionally (in either context) is one of the more underrated skills you can develop. And recognizing that it's the same state in both contexts made me appreciate both more.

What happens when the system breaks

Every distributed system has failure modes. Ours is a new hire who doesn't know the protocol yet.

Not their fault. Everyone is new once. But the implicit coordination that experienced baristas do automatically — the gap-filling, the priority sensing, the knowing-without-being-told — has to be learned. It can't be explained in an onboarding document. It has to be lived.

Until it's internalized, the system loses its magic a little. You notice the shots aren't pulled. You notice the register unstaffed for a beat too long. The constantly chugging streamlined machine gets a little choppy. The experienced people pick up the slack, which means they're covering their own work and watching for gaps the new person missed.

This is exactly what happens in distributed systems when a new node joins a network that relies on implicit protocol knowledge. The system degrades slightly until the node is calibrated. Then it recovers.⁵

The solution in both cases is the same: time, repetition, and patient experienced nodes who keep the system running while the new one learns.

The thing I didn't expect to learn

I didn't take the barista job to learn about computer science. I took it because rent is real and tips are nice and I genuinely like coffee.

But there's something that happens when you spend enough time in a domain that requires coordination, timing, and performance under pressure — you start to see the abstractions. The patterns. The ways that the problem you're solving in one context is the same problem showing up in a completely different one.

A morning coffee rush and a distributed database are not the same thing. But they are both solving the problem of coordinating parallel work without a central authority, under time pressure, with imperfect information. And the intuitions you build in one transfer to the other in ways that are hard to predict but very real.

I make better software for having made a lot of lattes. I'm almost certain of it.

Footnotes

¹ This is similar to a work-stealing algorithm used in parallel computing, where idle processors look for uncompleted tasks from other processors' queues rather than waiting to be assigned work. Wikipedia: Work stealing

² The formal definition of a distributed system comes from Andrew Tanenbaum: "a collection of independent computers that appears to its users as a single coherent system." Tanenbaum & Van Steen, Distributed Systems

³ Eventual consistency is a consistency model used in distributed computing where, given enough time without new updates, all nodes in the system will converge to the same value. Wikipedia: Eventual consistency

⁴ Flow state was first described by psychologist Mihaly Csikszentmihalyi as a state of complete immersion in an activity where time distorts and performance peaks. Wikipedia: Flow (psychology)

⁵ This is related to the concept of Byzantine fault tolerance in distributed systems — the ability of a system to continue operating correctly even when some nodes behave unexpectedly or incorrectly. Wikipedia: Byzantine fault