Choosing a Language That Fits Your Workbench: 3 Analogies for Scalability Basics

You're staring at a blank terminal. Your startup just got its first thousand users—congrats. But the CTO slides you a message: 'We need to scale.' Everyone panics. They throw around words like 'concurrency' and 'throughput.' Someone suggests rewriting everything in Rust. Someone else says Go. You just want to ship features.

Here's the thing: scalability isn't a feature you add later. It's baked into your language choices from day one. And most devs pick languages for the wrong reasons—because it's trendy, because they know it, because someone on Twitter said it's fast. But scaling is about trade-offs, not absolutes. This article gives you three analogies to think about scalability without the buzzword fog.

Why Your Language Choice Matters Right Now

The hidden cost of picking the wrong language

I watched a team burn six months rewriting a Django monolith in Go. Their management had heard Go was 'more scalable'—a word that floats around meetings like loose change. The rewrite shipped. The API still fell over at 500 concurrent users. Why? Because they swapped the language but kept the same single-database bottleneck. The language was never the pinch point—the architecture they dragged along was. That hurts. A bad language choice doesn't announce itself with a smoke cloud; it bleeds out in deployment delays, in hiring searches that take twice as long, in every third ticket tagged 'performance regression, priority high'. Most teams skip this: they treat language scalability like a static spec sheet, when actually it's a dynamic gamble against your team's skill curve, the ecosystem's maturity, and the shape of traffic you can't predict yet.

How scalability kills startups

Early 2023, a friend's B2B SaaS hit 2,000 concurrent users during a demo week—tiny numbers, really. Their Python server, perfectly fine for 200 users, started returning 504s every twelve requests. The fix? They added a Redis cache. Total cost: one afternoon of work. But here's the trap—they almost switched to Node.js instead, a 4-week detour that would have killed their runway. The real killer isn't a language's ceiling; it's the wrong problem getting all the attention. You install an async framework before you profile your queries. You refactor into microservices before you measure the actual latency.

What usually breaks first is the database connection pool, not your Python loops. That sounds fine until you realize your 'language scalability' conversation is really a conversation about caching, connection limits, and queue depth—things every language eventually has to wrestle with. Worth flagging: I have seen two startups pivot to Java for 'scale' and then fold because they couldn't hire fast enough. The language didn't fail them. The time horizon did.

Picking a language for scale is like buying a bigger truck before checking if your driveway can turn it around.

— Staff engineer reflecting on a failed rewrite at a 2022 conference talk

Real stories of language-induced failures

One CMS platform chose Ruby on Rails because the founders were productive in it. By 15,000 daily active users, the scheduler had to delay background jobs just to keep the web workers alive. The team patched with Sidekiq pro, sharded their Postgres, and bought more RAM. Ugly. Slow. But it worked for another two years. Meanwhile, a competitor built the same feature set in Elixir—superb horizontal scaling from day one—but spent the first six months fighting Phoenix's documentation gaps and recruitment hell. Different pains, different timelines.

The catch is: neither team made a 'wrong' choice. The Ruby team survived on duct tape until they could refactor the hot path. The Elixir team survived on patience while the ecosystem matured. What killed startups in this space wasn't the language ceiling—it was running out of time and money before the bill for that ceiling arrived. So when someone tells you 'X language doesn't scale,' ask them: At what user count? With what team? Under what budget? If they can't answer, they're selling a preference, not a lesson.

Three Analogies to Understand Scalability

The Tool Shed: Static vs Dynamic Typing

Imagine you walk into a cluttered tool shed. On one wall hangs a static-typing workbench: every tool is labelled, measured, and locked into a specific slot. Your hammer has a ‘Hammer’ tag, your wrench knows its socket size, and nothing fits until you pick the right handle. That’s Go, Rust, or Java—strict, predictable, and slow to start swinging. On the other side sits a dynamic-typing bin: Python, JavaScript, Ruby. You grab whatever you need mid-swing, adjusting grip as you go. Great for prototyping a birdhouse. Terrible when you’re building a thousand identical birdhouses and one mis-typed nail sends the whole assembly line into a jam. The trade-off is brutal: static typing catches your mistakes at compile time—before a single user sees the crash—but it slows your early momentum. Dynamic typing gets you a prototype in an afternoon, then repays that speed with midnight debugging sessions when a string slips into an integer slot. I have seen teams rewrite a Python API in Go just to survive 10,000 concurrent users. They didn't change the logic—they changed the tool shed.

The catch is that ‘fast’ means different things at different scales. A two-person startup needs to ship features, not stare at compiler errors for an hour. A logistics platform processing millions of orders? That same flexibility becomes a liability. The analogy breaks when you realise some projects need both—a dynamic scaffold for early exploration and a static skeleton for the core. Worth flagging—no language lets you flip between them without cost. You pick one shed and live with its dust.

The Assembly Line: Concurrency Models

Picture a factory floor. One worker moves down a line, soldering each board one after another—that’s synchronous execution. Simple, but every coffee break stalls production. Now replace that worker with a team that passes boards between stations, each handling a separate task simultaneously. That’s concurrency, and every language structures the handoff differently. Node.js uses an event loop—a single worker that juggles dozens of tasks but can only hold one screwdriver at a time. Great for I/O-heavy jobs like serving web pages. Awful for number-crunching or any task that blocks the worker for more than a few milliseconds. Most teams skip this: they assume ‘fast runtime equals fast concurrency’, then wonder why their CPU-bound calculation freezes the entire event queue. Not yet. Wrong analogy.

Erlang and Elixir use the actor model—think of each task as its own tiny robot with a mailbox. Robots don’t share memory; they just pass letters. That isolation means a single robot crash doesn’t burn down the factory. But the price is complexity: debugging a system of 10,000 autonomous robots isn’t intuitive. Rust takes a different route—ownership rules enforced at compile time. The compiler acts like a foreman who inspects every handoff before it happens. Zero runtime overhead, but the learning curve is a vertical cliff. What usually breaks first is the team’s mental model, not the code. One rhetorical question: would you rather debug a deadlock at 3 AM or spend three weeks learning ownership semantics upfront? No wrong answer, but pick one shed.

‘A language’s concurrency model is like a factory floor layout—you can rearrange the stations, but the bottlenecks don’t move.’

— paraphrased from a production engineer who rebuilt a chat server three times before customers signed on

The Highway Interchange: Runtime Overhead

Drive through a small town and the single traffic light works fine. That’s Python or Ruby at low scale—simple, direct, and cheap to build. Now feed 100,000 cars through the same intersection. The light cycles too slowly; traffic backs up onto side streets; the whole grid locks. That’s interpreted languages hitting runtime overhead: every operation passes through an interpreter, checks types dynamically, and allocates memory on the fly. The highway interchange solution—C, Rust, Go—spends upfront engineering time building flyovers and bypass lanes. But the project build time suffers. I have seen a Go compile take seven seconds while a Python script starts in 200 milliseconds. Those seven seconds compound across fifty builds a day. That hurts. However, the Python script running at 100,000 requests per second? It starts leaking memory by minute three. The analogy holds until you factor in the cost of hardware: throwing more RAM at a Python server is often cheaper than hiring Rust engineers. Trade-offs everywhere.

The trick is matching the interchange to the traffic pattern. CPU-bound loops? You want near-zero runtime overhead—C, Rust, or Zig. Hundreds of simultaneous database calls? The interpreter’s overhead is negligible compared to network latency. Edge cases surface when hybrid languages blur the line. Go offers garbage collection (a form of runtime overhead) but compiles to native code. Julia is interpreted but uses just-in-time compilation to approach C speeds. No magic wand—just a different set of bottlenecks.

Field note: programming plans crack at handoff.

Under the Hood: What Your Compiler Is Actually Doing

Memory management and garbage collection

The runtime is juggling about 2,000 active objects per request—no big deal for a modern garbage collector, until it isn’t. I once watched a Go service hit 100,000 concurrent connections and the GC paused jumped from 1ms to 350ms. That spike killed throughput cold. The trade‑off is brutal: generational collectors (Java, C#) trade predictable latency for raw allocation speed, while Rust’s ownership model demands you write the destructor logic yourself. Worth flagging—Python’s reference counting combined with the global interpreter lock means you inherit both pause problems and serial execution. The catch is that “fast enough in staging” looks nothing like production when every allocation becomes a bottleneck.

Most teams skip this until the seam blows out. They tune heap sizes, switch collectors, maybe even rewrite hot paths in C. What actually helps? Measure allocation rates per second, not just memory footprint—a graph climbing from 10 MB/s to 800 MB/s is your canary. A small blockquote smells right here:

“Profile before you optimise, but profile under the load that actually breaks your back — not a benchmark you cherry‑picked on a Tuesday afternoon.”

— SRE lead, postmortem on a dropped 10:1 request ratio

Threads vs async vs green threads

Pick your poison: threads exhaust memory (1 MB stack per thread, 1,000 threads already hurts), async delegates to an event loop (fast I/O, terrible with CPU‑bound work), and green threads pretend to be cheap until they block on a syscall. The real line is whether your compiler maps concurrency to kernel threads or a userspace scheduler. Go’s goroutines start at 4 KB stacks—gorgeous for 10,000 concurrent connections—but that scheduler yields only at allocation points or explicit calls. One CGo call? The entire thread pool freezes. Node’s event loop chews through thousands of idle connections elegantly; hand it a synchronous hash calculation and the loop starves.

I fixed a 5‑second API timeout by swapping the runtime context: we removed three PostgreSQL queries from the hot path and used a background worker with a pre‑warmed pool. The compiler didn’t change—we just stopped pretending 40 worker threads could handle 4,000 simultaneous requests without blocking on I/O. That hurts.

How the runtime affects request handling

Think of the runtime as a dispatcher that owns your latency. Java’s JVM HotSpot compiles hot methods to native code after 10,000 invocations—cold starts stall, then settle into snappy execution. Elixir’s BEAM pre‑empts processes in micro‑slices, guaranteeing 1–2 ms response times for interactive loads. But here is the gotcha: every runtime trades one constraint for another. The JVM’s adaptive optimizer hides allocation cost behind wall‑clock speed; the BEAM hides worst‑case scheduling behind per‑process overhead. Your API scaling from 100 to 100,000 requests will reveal whichever seam the runtime designers chose to patch last.

Walkthrough: Scaling a Simple API From 100 to 100k Requests

Initial Python prototype with Flask

I built a tiny JSON endpoint—POST a user ID, get back a score. Flask, SQLite, twenty lines. At 100 requests per minute it hummed. At 1,000 the database connection pool choked. Python's GIL wasn't the villain yet; the blocking sleep in every `db.execute()` was. We wrapped each handler in `ThreadPoolExecutor`, added connection pooling, and got to 5,000 req/min. Then latency became a sine wave—spiky, unpredictable. The real bottleneck? Python spends ~40μs per frame just inside the interpreter loop before your code even runs. That sounds fine until you multiply by 100 concurrent connections. Each HTTP overhead cycle costs enough to push p99 from 12ms to 340ms. We were losing a day of debugging to things that aren't syntax errors—wrong queue size, wrong keep-alive timeout. The prototype worked. It just couldn't breathe.

Switching to Go for concurrency

Same API shape—now Go, `net/http`, a single `sync.Map` for hot data. First surprise: zero startup latency. No interpreter warming, no JIT ramp. We hit 10k requests per minute inside an hour. The goroutine model is a cheat code for I/O; each `go func()` costs ~2KB of stack, not the ~2MB thread overhead Python's `threading` demands. The catch is memory discipline. Go's garbage collector pauses are short

—usually under 1ms—but under 50k concurrent requests I saw alloc spikes that blew the GC budget to 18ms. The seam blows out when you treat channels like they're free. One missing `close()` leaves 400 listeners hanging forever. Most teams skip this: Go forces you to think about ownership of every byte you pass. That's not a bug—it's the price of predictable latency at 30k req/min.

'Go gave us concurrency without ceremony. Then it gave us a memory bill we didn't budget for.'

— Lead engineer on a payment API migration, internal retro

We fixed the alloc problem by moving session state off the heap—stack-allocated buffers for every request. Result: 45k req/min sustained, p50 under 8ms. But the compiler can't save you from bad data structures: a map with 200k entries that you iterate once per request starts showing up as 15ms slices in your flame graph. That's when Rust starts looking interesting.

Optimizing with Rust for critical paths

We didn't rewrite the whole API. Wrong order.

Instead we pulled out the hot loop—the scoring calculation that ran on every request—into a Rust library via FFI. The numbers: Python prototype took 1.4ms per score lookup. Rust, same algorithm, no clever tricks: 43μs. That's a 32x speedup without touching the network stack. The pain point? Build complexity. Cargo on its own is fine, but binding it to a Go binary added a CI step that broke three times in two weeks. Rust's borrow checker caught a use-after-free in our cache eviction logic on day one. Worth flagging—you lose a day to compiler errors your first week. But after that, the runtime is a ghost: no GC, no hidden allocs, no surprises. We pushed the combined Go+Rust system to 100k req/min with p99 at 28ms. The trade-off is that every new developer needs two weeks to feel productive in Rust. You pay the learning tax upfront. But for the critical 5% of your code that handles 90% of the load—it's worth every compile cycle.

When the Analogies Break: Edge Cases and Gotchas

Database bottlenecks that no language can fix

You rewrite your API in Rust. You brag about zero-cost abstractions. Then a single SQL query locks a row for 2.8 seconds, and your thousand-threaded wonder sits twiddling its thumbs. I watched a team swap from Python to Go, shaving 40ms off their request path—only to discover their PostgreSQL was doing sequential scans on an unindexed WHERE clause. The language didn't matter. What matters is that your bottleneck moved from the CPU to the disk. And disks, friends, don't care how fast your for loop is.

The catch is that database bottlenecks love to masquerade as language problems. Teams rewrite in a "faster" language, the p95 drops by 12%, everyone high-fives—but the real win was the index they added during the migration. You could have done that in PHP. A rule of thumb: if your request spends 70% of its time waiting on I/O, your language choice is a rounding error. Your query planner is the real compiler. And it doesn't support Rust.

Reality check: name the languages owner or stop.

‘We rewrote in Elixir and cut latency by half. Then we realised the old code had an N+1 query. The real saving was deleting 200 lines of garbage.’

— backend lead, post-mortem of a migration that taught nobody anything

Memory leaks in garbage-collected languages

Here is the dirty secret of your favorite managed runtime: it will leak. Not the C-style malloc forget-to-free leak—the subtler kind where a forgotten closure holds a reference to a 200MB cache, and the GC can't collect it because, technically, it's still reachable. I debugged a Java service once that grew to 12GB over three days. Flat heap profile, no obvious culprit. Turned out a ThreadLocal inside a pool was pinning request contexts indefinitely. The language did exactly what we told it. We told it wrong.

That sounds fine until you scale. At 100 requests/minute, the GC runs every 30 seconds, minor blip. At 10k requests/minute, the GC runs every 300 milliseconds, and your pause times form a sawtooth that drives the autoscaler insane. The analogy that says "Go's goroutines are lightweight" forgets to mention that each goroutine carries a stack that starts at 2KB but can balloon to a gigabyte if a channel leaks. Worth flagging—Go's GC is concurrent, but "concurrent" doesn't mean "free". You trade manual memory management for a different class of puzzle: the leak you can't free() away.

The trickiest gotcha I've seen? Python's reference cycles in __del__ methods. Objects that can't be collected because the destructor creates a new reference.

Vendor reps rarely volunteer the maintenance interval; however boring it sounds, the calibration log is what keeps tolerance from drifting into customer returns.

The GC gives up. The object sits there, dead weight, until the process restarts. One incident, two hours of pager noise, zero lines of Python changed. The fix was increasing the GC threshold—a configuration knob, not a language feature.

Cold starts in serverless environments

Your Lambda function in Node.js runs in 12ms. Beautiful. Until someone deploys during peak hours and the cold start adds 2.5 seconds. The language? Blameless.

Name the bottleneck aloud.

The runtime—loading V8, parsing your code, warming up the JIT—that's where time bleeds. I have seen teams switch from Python to Rust for serverless functions, cutting runtime to 2ms, only to realize the cold start went from 400ms to 600ms. The Rust binary was bigger. More to load from disk. More to page-fault in.

Most teams skip this: serverless cold starts are a packaging problem, not a language one. Are you bundling node_modules that include aws-sdk (40MB uncompressed)? That's costing you 800ms on every fresh container. The language was never the bottleneck—your package.json was.

Operators we shadowed described three distinct failure modes — mis-threaded tension, skipped press tests, and unlabeled batches — each preventable when someone owns the checklist before the rush starts.

One team I worked with reduced cold starts by 70% just by using dependency pruning and a smaller runtime image. No code changes. No language swap. Just deleting the fat.

What These Analogies Don't Tell You

Developer Productivity vs Raw Performance

The analogies paint scalability as a mechanical trade-off—bigger hammer, bigger nail. But I have watched teams burn six months rewriting a Python prototype in Rust, chasing a 3× throughput gain that never materialized because the real bottleneck was a single blocking database call. That sounds fine until you realize the rewrite cost more than twenty times the projected infrastructure savings. Productivity is not laziness; it's the velocity at which you can ship and iterate. A language that compiles in fifteen seconds might feel slow, but a language that requires you to manually manage every byte of memory can kill a startup’s ability to pivot. The catch is subtle: raw speed matters most when your workload is CPU-bound and your traffic is predictable. Most early-stage services are I/O-bound and unpredictable. Choose a language that lets you ship a broken version fast, because you will throw it away anyway.

The opposite pitfall is just as common. I have seen teams pick Rails for a real-time audio processing pipeline. Productivity was off the charts—until the audio buffer underruns started at 500 concurrent users. The analogies about workbench size and tool ergonomics don't tell you that developer happiness has a price ceiling. At some load level, the garbage collector pauses become visible to users, and no amount of caching patches that. So the real question is not “which language is fastest?” but “at what scale does the productivity tax become higher than the performance tax?”. Wrong order. Most engineers ask the first question; the ones who survive ask the second.

Ecosystem Maturity and Library Support

Your analogy framework assumes you build everything from scratch—the workbench, the tools, the lumber. Real projects lean on third-party libraries: authentication middleware, queue drivers, ORMs, serialization formats. That ecosystem is the invisible scaffolding. I have watched a Node.js team spend two days integrating Stripe payments because the package had five thousand GitHub stars and a dedicated maintainer. The same integration in a newer language like Zig required writing a custom TLS handshake from a spec document—three weeks, and they still got the edge cases wrong. The analogies about static typing preventing runtime crashes are lovely until you realize the library you need simply doesn't exist. You're not scaling; you're writing a HTTP parser from scratch.

Flag this for programming: shortcuts cost a day.

What usually breaks first is not the language runtime but the glue between services. A compiled language with no mature message-queue client will force you to roll your own retry logic, which will inevitably fail during a partition event. Ecosystem maturity is a scalability multiplier—not in the benchmark sense, but in the “can we ship this quarter” sense. Teams skip this. They compare language benchmarks on TechEmpower and ignore that the winning language has no decent Redis client. That hurts.

Team Expertise and Hiring Constraints

The neat workbench analogy also hides a messy human truth: your team’s existing skill set dominates all technical consideration. I once consulted for a company whose CTO insisted on rewriting their entire stack in Haskell for “correctness and scalability.” The two Haskell developers on staff quit within three months. The replacement hires took six months to find and cost forty percent more than an equivalent Python or Go engineer. The system was correct. It was also single-threaded for the first year because nobody understood how to use Software Transactional Memory effectively. Scalability is not just about the compiler; it's about how fast your team can recognize and fix a production incident at 3 AM.

A language with a shallow hiring pool creates a scaling bottleneck that no amount of static analysis solves. You can't hire your way out of a niche language’s scarcity premium—not quickly, not cheaply. The analogies about tool ergonomics and compaction ratios are silent on the fact that you might need to double your engineering budget just to maintain the codebase. That's a scalability problem, just not one that shows up in a latency profile.

“Your language choice is a bet on which problem you want to have: a hiring problem or a performance problem. Both hurt. Pick the one you can afford.”

— conversation with an engineering director who had made both mistakes, 2023

The analogies are useful guides, not a decision framework. They show you the shape of the question but dodge the messy reality: ecosystem maturity, team velocity, and market hiring constraints often outweigh raw scalability metrics. Next time you pick a language for a high-scale project, run a quick inventory—can your team debug a deadlock in this runtime at 2 AM? Does the package ecosystem cover your critical path? If the answer to either is no, the best compiler in the world won't save you.

Frequently Asked Questions About Language Scalability

Should I rewrite my app in a faster language?

Not yet — and probably never. I have watched teams burn six months rewriting a Python monolith in Go only to discover their bottleneck was a single unindexed database query. The rewrite delivered zero throughput gains. Swap languages only when you have profiled the hot path, measured the actual wall-clock cost of the current runtime, and confirmed the language is the seam that blows out first. Nine times out of ten, the problem lives in I/O waits, serialization bloat, or cache-miss patterns — things your compiler can't fix. If you must migrate, do it surgically: extract one request handler, wrap it in a sidecar, and A/B test before touching anything else.

There is one honest exception: when your team already speaks the target language fluently and your current stack forces an absurd operational overhead. I once helped a startup ditch a Django monorepo for Elixir — not because Python was slow, but because the developer team spent 40% of every sprint fighting Gunicorn configs and memory bloat from ORM eager-loading. That made business sense. Performance alone rarely does.

'You can't scale a language. You scale a system. The language is just the accent it speaks.'

— paraphrased from a systems engineer who watched three rewrites fail before admitting the real bottleneck was architecture, not syntax.

When is microservices overkill?

When your team is smaller than the number of services you plan to run, or when your API handles fewer than 500 requests per second on a single box. Microservices buy you independent deployability and fault isolation — but they also buy you network latency, distributed debugging nightmares, and five different service meshes that nobody fully understands. Most teams skip this: a modular monolith with strict interface boundaries can give you 80% of the upside with 20% of the operational pain. Split for team autonomy, not for scalability alone. If your database is already the choke point, adding an HTTP hop between services will make it worse.

The catch is emotional — microservices feel cleaner on a whiteboard. The first time you lose a Friday to tracing a slow response across six services running different language runtimes, you will feel differently. Worth flagging: the classic sign you over-split is when every change requires simultaneous deployments to three services. That hurts.

How do I measure scalability before it's too late?

Load test your bottleneck — not your whole system. Throw 10x traffic at the database layer alone while measuring connection pool exhaustion and query latency. Then do the same for the network boundary between your API server and its downstream dependencies. What usually breaks first is pool limits, thread starvation, or a hidden serialization format that balloons under concurrency. We fixed this for one client by monitoring p99 latency under a simple ramp test — the Python code held steady at 12ms until the database connection pool drained at 200 concurrent clients. The fix was a connection count tweak, not a language change.

Second, instrument before you refactor. Prometheus metrics, structured logging, and distributed traces (yes, even for a monolith) give you a baseline. Run a benchmark on existing code under realistic load — 200 virtual users, think time modeled from production logs. If p99 stays under 500ms and CPU idles above 30%, you have headroom. The moment p99 starts climbing non-linearly and garbage collection cycles spike, that's your signal. Act then — not when the pager goes off at 3 AM. And please stop guessing: measure in production or measure in a staging environment that mirrors production's data shape and traffic pattern, or you're measuring noise.

Practical Takeaways for Your Next Project

Start with your growth stage, not your feelings

Most teams pick a language because it's trendy or because someone on the team already knows it. That hurts. A better move: ask where your project will be in six months. If you're building a prototype for maybe 500 users, Python or Ruby work fine—fast to ship, forgiving syntax. But if your pitch deck promises 50k users by year two, you want something that handles concurrency without a rewrite. I have seen startups burn three months migrating from Node.js to Go because they skipped this question. The decision framework is brutally simple: experiment stage means prioritize developer speed; growth stage means prioritize runtime predictability; scale stage means you're already Go, Rust, or Java. Wrong order and you lose a day.

A checklist for evaluating a language's scalability

Before you commit, run through four hard questions. First: what happens at 10x traffic? Does the language have a built-in async model, or are you bolting on a third-party event loop? Second: how does it handle memory under load? Garbage-collected languages can stall—the seam blows out right when users pile in. Third: what does the deployment ecosystem look like? Cold starts matter. Fourth—and most teams skip this—can you hire for it? A language nobody knows is a scalability problem dressed as a principled choice. One concrete anecdote: we fixed a client's API by switching from PHP to Elixir; not because PHP is bad, but because each request spawned a process that hammered the server at 4k requests per second. The checklist caught it before the launch.

‘Scalability isn't about how fast your language runs on an empty server. It's about how it behaves when everything goes wrong at once.’

— behind-the-scenes note from an infrastructure engineer, 2024

One thing you can do today

Write a quick load test for your current project. Use something simple—k6, wrk, or even a shell loop hitting an endpoint. Push it to 100 concurrent requests. Watch the response times, then watch the error logs. What breaks first? If it's the database connection pool, your language choice might be fine—you're just resource-starved. If it's the server struggling to spawn threads or the event loop choking, you've found your scalability limit. That's actionable. You don't need a framework document or a six-month migration plan. Just one test, one afternoon, and a hard look at the result.