December 28, 2025
10,000 users, 1 million opinions
We "solved" C10K years ago yet we keep reinventing it (2003)
We solved serving 10,000 users—now commenters claim JavaScript broke it again
TLDR: A 2003 guide says serving 10,000 simultaneous users is achievable with smart software, not just bigger machines. Commenters say it’s already solved, flex modern server power, and blame server-side JavaScript for reviving the pain—proof that scale problems keep returning and matter for every app that wants to stay fast.
Today’s thread dusts off a 2003 guide to the “C10K problem”—how to serve 10,000 people at once—and the crowd arrives with elbows out. Old-schoolers say the hardware caught up ages ago and the techniques are documented: think smarter input/output and lean frameworks. One brag drops like a mic: with nginx and 256‑core Epycs, one box blasts “200k requests per sec.” Another commenter shrugs, “I don’t think I even heard of C10K until around 2003,” turning the whole thing into a nostalgia tour.
But the real spice? A jab: “We solved it 2 decades ago but then decided to use JavaScript on the server,” which sets off the front-end vs back-end culture war, again. Another joker turns it into fitness meme time: “It’s more of a C25K time of year.” Meta‑commenters note this classic resurfaces every few years—2014’s thread smashed, 2007’s barely blinked.
In simple terms: the old essay says the internet’s party hosts can handle 10,000 guests if the house rules are smart and not wasteful. The audience agrees—mostly—but can’t resist arguing whether today’s shiny tools keep breaking the furniture. The mood: equal parts victory lap, tech history lesson, and snarky stand‑up. Everyone’s right, and everyone’s loudly right. Today.
Key Points
- •By the early 2000s, commodity hardware could support tens of thousands of concurrent clients; hardware was no longer the main bottleneck.
- •In 1999, cdrom.com served 10,000 simultaneous clients over Gigabit Ethernet; by 2001, gigabit service was offered by multiple ISPs.
- •The article outlines I/O strategies: many clients per thread, nonblocking I/O with level-triggered readiness, and asynchronous I/O with completion notifications.
- •Frameworks such as ACE (Reactor/Proactor), ASIO (Boost), and libevent (supporting kqueue/select, planned poll/epoll) help implement scalable servers.
- •Benchmarks by Felix von Leitner (2003) indicate Linux 2.6 outperforms Linux 2.4; kqueue and epoll show strong scaling in event handling.