The Ghost in the Machine: Why C10K Still Haunts Us
Here's a confession: I've built systems that handle millions of concurrent connections. I've worked with async frameworks, event loops, and all the modern concurrency primitives. And yet, just last month, I found myself debugging what was essentially a C10K problem—just dressed up in 2025's fanciest abstractions.
That Reddit discussion hit a nerve because it's painfully true. We keep solving the same problems under different names. The original C10K article wasn't really about handling exactly 10,000 connections—it was about understanding where systems actually break. And those breaking points? They haven't changed much. They've just gotten better at hiding.
In this article, we're going to explore why these fundamental constraints keep resurfacing. We'll look at how modern abstractions sometimes obscure rather than eliminate complexity, why backpressure remains a perennial challenge, and what you can do to avoid falling into these same traps. By the end, you'll have a clearer picture of what really matters when building scalable systems in 2025.
The Original Insight: What C10K Actually Taught Us
Let's rewind for a moment. When Dan Kegel wrote that original article, he was pointing at something deeper than just "how to handle lots of connections." He was highlighting fundamental architectural decisions that either enable or prevent scalability.
The thread-per-connection model was the obvious villain. Creating an OS thread for each connection consumed too much memory and created too much context-switching overhead. But the real insight was about understanding system limits—not just at the application layer, but deep in the kernel, in the hardware, in the network stack.
What's fascinating is how many of those limits still exist, just at different scales. File descriptor limits? We've bumped them up, but they're still there. Context switching overhead? Modern CPUs handle it better, but it's still expensive. Memory per connection? We've optimized, but physics hasn't changed.
The tools have evolved dramatically. We have async/await in practically every language now. We have coroutines, fibers, virtual threads, and all sorts of fancy concurrency primitives. But the underlying constraints? They're remarkably similar. We're just playing the same game on a bigger field.
Event Loops vs Threads: The Eternal Debate
Here's where things get interesting. The original C10K solutions leaned heavily on event loops—select(), poll(), epoll(), kqueue(). These were the weapons of choice for handling massive concurrency with minimal overhead.
Fast forward to 2025, and we're having the same debate, just with different terminology. "Should I use async/await or threads?" "Are virtual threads the answer?" "What about Go's goroutines?"
From what I've seen, the answer hasn't changed much: it depends on your workload. Event loops (and their modern async/await descendants) excel at I/O-bound workloads with many concurrent connections doing relatively little computation. Threads—especially with modern implementations—can be better for CPU-bound work or when you need blocking semantics without the cognitive overhead of async.
But here's the trap I see developers falling into repeatedly: they choose an abstraction because it's popular, not because it fits their problem. I've seen teams implement complex async systems for workloads that would have been perfectly served by a thread pool. I've seen others use blocking I/O for systems that needed to handle tens of thousands of connections.
The real lesson? Understand your workload first. Profile it. Measure it. Then choose your concurrency model. Don't just reach for the shiniest new abstraction because everyone on Hacker News is talking about it.
Async Abstractions: Hiding Complexity, Not Eliminating It
This might be the most important point from that Reddit discussion. Modern async abstractions are fantastic—they make concurrent programming more accessible, more readable, and often more performant. But they hide complexity rather than eliminate it.
Let me give you a concrete example from my own experience. I was working with a team that had built a microservice using async/await throughout. It worked beautifully—until it didn't. Under heavy load, the system would just... stop. No errors, no crashes, just unresponsiveness.
After days of debugging, we found the issue: a single blocking call deep in a dependency. Just one synchronous database query in an otherwise async stack. That one blocking call was starving the event loop, preventing other tasks from making progress.
The async abstraction had hidden the complexity so well that the developers didn't even realize they needed to think about blocking operations. The framework promised "just add async/await and everything scales!" But that's not how it works in practice.
Similar issues show up with backpressure, resource limits, and error handling. Async code makes it easy to fire off thousands of requests, but what happens when the downstream service can't handle them? What happens when you run out of file descriptors or memory?
The abstraction doesn't solve these problems—it just moves them to a different layer. And if you're not aware of that layer, you're going to have a bad time.
Backpressure and Resource Limits: The Silent Killers
If there's one area where we keep rediscovering C10K-era lessons, it's backpressure. The concept is simple: when a component can't keep up with incoming data, it needs a way to signal "slow down!" to upstream components.
In practice? It's incredibly difficult to get right.
I've seen systems that handle backpressure beautifully at one layer—say, between the application and the database—but completely ignore it at another layer, like between microservices. The result is cascading failures that are incredibly difficult to debug.
Modern frameworks and protocols have gotten better about this. HTTP/2 and HTTP/3 have flow control built in. Reactive streams specifications provide backpressure mechanisms. But here's the thing: you still have to understand them. You still have to implement them correctly. And you still have to test them under realistic load.
Resource limits are similar. We've moved from worrying about 10,000 file descriptors to worrying about 100,000 or a million. But the fundamental problem remains: resources are finite. Memory, CPU, network bandwidth, database connections—they all have limits.
The worst systems I've seen are the ones that pretend these limits don't exist. They allocate memory without bounds, create connections without pools, and assume the network is infinitely fast and reliable. These systems work fine in development and testing, then fall over spectacularly in production.
The systems that survive? They're the ones that acknowledge limits from day one. They monitor resource usage. They implement circuit breakers and rate limiting. They understand that scaling isn't just about handling more requests—it's about handling more requests within constraints.
Hardware Scaling: Naive Assumptions in 2025
Here's something that hasn't changed since the original C10K article: our assumptions about hardware scaling are often wrong.
In the early 2000s, the assumption was that CPU speeds would keep increasing exponentially. That didn't happen—instead, we got more cores. Today, I see similar naive assumptions about cloud scaling. "The cloud is infinite!" "We can just add more instances!" "Auto-scaling will handle it!"
But the cloud isn't infinite. It has limits—API rate limits, instance type availability, regional capacity, network bandwidth between availability zones. I've seen systems fail not because of application bugs, but because they hit cloud provider limits that the developers didn't even know existed.
And auto-scaling? It's a fantastic tool, but it's not magic. It takes time to spin up new instances. It requires careful configuration of metrics and thresholds. It can create feedback loops that make problems worse rather than better.
The most resilient systems I've worked on treat scaling as a first-class concern, not an afterthought. They understand their scaling characteristics—how much load each instance can handle, how long it takes to scale up or down, what the bottlenecks are. They test scaling under load, not just functionality.
This is where the C10K mindset remains valuable: understand your system's actual limits, not just the theoretical ones. Measure everything. Test at scale. Know where you'll break before your users do.
Practical Strategies for 2025 and Beyond
So what should you actually do? How do you build systems that don't keep rediscovering these same problems?
First, embrace observability. I'm not just talking about logging errors—I mean real, deep observability. Metrics for resource usage (memory, CPU, file descriptors, connections). Distributed tracing to understand request flow. Structured logs that you can actually query. Without this, you're flying blind.
Second, load test early and often. Don't wait until you're about to launch to see if your system can handle the load. Test with realistic traffic patterns. Test failure scenarios. Test scaling up and down. I've found that teams that load test from the beginning make fundamentally different architectural decisions than teams that don't.
Third, understand your tools' limits. That async framework you're using? Read the documentation about its concurrency model. Understand how it handles blocking operations. Know its memory overhead per connection. The same goes for databases, message queues, and any other infrastructure components.
Fourth, implement backpressure at every layer. This is non-negotiable for production systems. Whether it's through reactive streams, HTTP/2 flow control, or custom mechanisms, you need a way to signal when you're overloaded. And you need to respect those signals from downstream services.
Finally, keep it simple where you can. Not every service needs to handle millions of concurrent connections. Sometimes a simple thread pool is the right solution. Sometimes synchronous I/O is fine. Choose the simplest solution that meets your actual requirements, not your imagined future requirements.
Common Mistakes and FAQs
"But my framework handles concurrency for me!"
I hear this all the time. And yes, modern frameworks do an amazing job of abstracting away concurrency details. But they can't abstract away physics. They can't make blocking I/O non-blocking. They can't eliminate resource limits. You still need to understand what's happening under the hood.
"We'll just scale horizontally when we need to."
Horizontal scaling solves some problems but creates others. Now you have to worry about shared state, consistency, network partitions, and coordination between instances. These are hard problems—often harder than vertical scaling. Don't assume horizontal scaling is a magic bullet.
"Our cloud provider handles availability."
Cloud providers give you tools for availability, but they don't guarantee it. You still need to design for failure. You still need multi-region deployments if you want true high availability. You still need to handle instance failures, network partitions, and regional outages.
"We'll optimize when we have performance issues."
This is the most dangerous assumption of all. By the time you have performance issues in production, you're already losing users or money. And performance optimizations often require architectural changes that are difficult to make late in development. Design for performance from the beginning.
Moving Forward Without Reinventing
So here we are in 2025, still talking about problems that were identified decades ago. But that's not necessarily a bad thing—it means these are fundamental constraints, not temporary limitations.
The key insight from the original C10K article remains true today: scalability isn't about any single technique or technology. It's about understanding your system's actual limits and designing within them. It's about making informed trade-offs between complexity and performance. It's about testing your assumptions before they're tested by your users.
The tools will keep changing. New abstractions will keep appearing. But the fundamental constraints—finite resources, the cost of context switches, the reality of blocking operations—those aren't going anywhere.
My advice? Learn the fundamentals. Understand how your operating system handles I/O. Know how your programming language's concurrency model actually works. Measure everything. Test at scale. And when you're evaluating a new framework or technology, ask yourself: is this solving a real problem, or just hiding it behind a new abstraction?
The C10K problem was never really about 10,000 connections. It was about understanding systems at a fundamental level. And that's a problem worth solving—and remembering—no matter what year it is.
