Why I Rewrote My App in Rust: A Performance Journey That Changed Everything

The 3 AM Wake-Up Call

I'll never forget the Slack notification that woke me up at 3:17 AM: "Server costs up 340% this month. Need explanation ASAP."

My side project—a simple URL shortener that had somehow gone viral on Product Hunt—was hemorrhaging money. What started as a weekend hack serving 100 requests per day was now handling 50,000. And my Node.js server was screaming.

I did what any sleep-deprived developer would do: I threw more servers at it. Then more. By week's end, I was running eight EC2 instances where one should've been enough. The AWS bill looked like a phone number.

That's when I made a decision that seemed crazy at the time: I'd rewrite the entire thing in Rust.

Why I Was Terrified (And Did It Anyway)

Let me be honest—I'd been avoiding Rust for years. The learning curve looked like a cliff face. The borrow checker sounded like a judgmental robot that would reject all my code. And I'd heard the horror stories: developers spending hours fighting the compiler over lifetimes and ownership.

But I was desperate. And I'd read enough benchmarks to know that Rust could theoretically handle 10x the traffic with a fraction of the resources.

So I carved out two weeks. Told my partner I'd be "in the zone." Stocked up on coffee. And dove in.

The First Week: Fighting the Compiler (And Losing)

Day one was humbling.

My first Rust program—a simple HTTP endpoint that returned "Hello, World"—took me four hours. Four hours! I could've written the same thing in Node.js in four minutes.

The compiler rejected everything. "Cannot move out of borrowed content." "Lifetime parameter mismatch." "Expected &str, found String." I felt like I was learning to code all over again.

But here's the thing: every error message was actually helpful. The Rust compiler doesn't just say "no"—it explains why and often suggests fixes. It's like having a patient (if strict) mentor looking over your shoulder.

By day three, something clicked. I stopped fighting the borrow checker and started listening to it. Those errors? They were catching bugs I didn't even know I had. Race conditions. Memory leaks. Null pointer dereferences that would've crashed my Node.js app in production.

The compiler was annoying, sure. But it was also right.

The Rewrite: What Actually Changed

My URL shortener was conceptually simple:

• Accept a long URL via POST request
• Generate a short code
• Store the mapping in Redis
• Redirect short codes to original URLs
• Track analytics (clicks, referrers, timestamps)

The Node.js version was about 800 lines of JavaScript across multiple files. The Rust version ended up being roughly 1,200 lines—but that included proper error handling, type safety, and zero runtime exceptions.

Here's what the core redirect handler looked like in Node.js:

app.get('/:code', async (req, res) => {
  const url = await redis.get(req.params.code);
  if (!url) return res.status(404).send('Not found');

  // Fire and forget analytics
  trackClick(req.params.code, req.ip, req.headers.referer);

  res.redirect(301, url);
});

And in Rust (simplified):

async fn redirect(
    Path(code): Path<String>,
    State(state): State<AppState>,
) -> Result<Redirect, StatusCode> {
    let url = state.redis
        .get(&code)
        .await
        .map_err(|_| StatusCode::INTERNAL_SERVER_ERROR)?
        .ok_or(StatusCode::NOT_FOUND)?;

    tokio::spawn(track_click(code, state));

    Ok(Redirect::permanent(&url))
}

More verbose? Yes. But every error case is handled explicitly. The types tell you exactly what can go wrong. And the compiler guarantees I'm not forgetting edge cases.

The Benchmarks: Numbers That Made Me Gasp

After two weeks of development, I had a working Rust version. Time to see if the pain was worth it.

I used wrk to benchmark both versions on identical hardware (4-core, 8GB RAM):

Node.js (v18, cluster mode, 4 workers):

• Requests/sec: 8,234
• Latency (avg): 12.3ms
• Latency (p99): 47ms
• Memory usage: 420MB
• CPU usage: 340% (across all cores)

Rust (Axum + Tokio):

• Requests/sec: 94,127
• Latency (avg): 1.1ms
• Latency (p99): 3.2ms
• Memory usage: 12MB
• CPU usage: 180%

I ran the tests three times because I didn't believe the numbers.

11x more requests per second. 11x! And that's not even the best part—the memory usage dropped by 97%. The p99 latency was 15x better.

But the real kicker? Under load, the Node.js version would occasionally spike to 200ms+ latency when garbage collection kicked in. The Rust version? Consistent as a metronome. No GC pauses. No event loop blocking. Just predictable, blazing-fast responses.

The Real-World Impact

I deployed the Rust version on a single t3.small instance—the smallest production-grade server AWS offers. It handled the same traffic that previously required eight t3.medium instances.

Monthly AWS costs:

• Before: $847
• After: $24

That's a 97% reduction. I was literally saving $800+ per month.

But the performance improvements weren't just about cost. Users noticed. My analytics showed:

• Bounce rate dropped 23%
• Mobile users (who are more latency-sensitive) increased 31%
• Average session duration up 18%

Faster apps aren't just cheaper to run—they're better for users.

What I Learned (The Hard Way)

1. The Compiler Is Your Friend

This sounds like Stockholm syndrome, but I mean it. After fighting the borrow checker for two weeks, I started to trust it. When I went back to write some JavaScript, I felt naked. No one was checking my work. No one was preventing me from shooting myself in the foot.

Rust's strictness isn't punishment—it's protection.

2. Async Rust Is Tricky (But Worth It)

The async ecosystem in Rust is powerful but fragmented. Tokio vs async-std. Different runtime flavors. Confusing lifetime issues with async traits.

I spent a full day debugging why my Redis connections were hanging, only to discover I was accidentally blocking the async runtime with a synchronous call. The error messages here are less helpful than with ownership issues.

But once you understand the mental model—that async Rust is about cooperative multitasking, not threads—it clicks. And the performance is unreal.

3. The Ecosystem Is Maturing Fast

Three years ago, I would've struggled to find good web frameworks. Today? Axum, Actix-web, Rocket—all production-ready. The crate ecosystem (Rust's package registry) has high-quality libraries for everything I needed.

I was particularly impressed by:

• Serde: JSON serialization that's both fast and type-safe
• Tokio: Async runtime that just works
• Anyhow: Error handling that doesn't make you want to cry

4. Rust Won't Magically Fix Bad Architecture

Here's an uncomfortable truth: my first Rust version was only 3x faster than Node.js. Not 11x.

Why? Because I'd ported my bad Node.js patterns directly to Rust. I was still making unnecessary Redis calls. Still serializing data inefficiently. Still using suboptimal algorithms.

The 11x improvement came from rethinking the architecture. Rust's performance ceiling is high, but you still need to write good code to reach it.

Would I Do It Again?

Absolutely—but not for every project.

Rust makes sense when:

• Performance matters: High-traffic services, real-time systems, resource-constrained environments
• Reliability is critical: Financial systems, infrastructure tools, anything where crashes are expensive
• Long-term maintenance: The type system makes refactoring safer and easier

Rust is overkill when:

• You're prototyping and need to move fast
• Your bottleneck is I/O, not CPU (though Rust still helps with memory)
• Your team isn't ready for the learning curve

For my URL shortener? It was the right call. The performance gains paid for themselves in weeks. The reliability improvements gave me peace of mind. And honestly? I sleep better knowing the compiler has my back.

The Unexpected Benefit

Here's something I didn't anticipate: learning Rust made me a better programmer in every language.

I think more carefully about ownership now, even in JavaScript. I consider error cases more thoroughly. I'm more conscious of memory allocation and performance implications.

Rust didn't just make my app faster—it made me better.

Your Turn

If you're considering Rust, my advice: start small. Don't rewrite your entire production system. Pick one performance-critical service. One background worker. One CLI tool.

Fight the compiler. Lose a lot. Then slowly start winning.

The learning curve is real. But so are the rewards.

And who knows? Maybe you'll also get to delete seven servers and sleep through the night again.

---

Want to see the code? I've open-sourced both versions on GitHub. The benchmarking scripts are included so you can reproduce the results yourself. And if you're starting your Rust journey, feel free to reach out—I remember how lonely those first few weeks felt.

Now if you'll excuse me, I have some AWS credits to spend on something more interesting than keeping Node.js alive.