Why I'm Finally Taking Rust Seriously After Building a Real Product

I've been that developer who dismisses Rust as "overkill for web backends." You know the type—I've shipped plenty of production Node/Python services, things work fine, and I didn't have time for borrow checkers and compilation headaches. Then I read about someone building a 100k-clip Chinese learning platform with Rust and Next.js, and something shifted. Not because Rust is suddenly sexy, but because they made concrete tradeoffs I couldn't ignore: predictable latency, zero garbage collection pauses, and a 2-core VPS that doesn't sweat under load. That's not theory. That's production reality.

The more I dug into their architecture, the more I realized I've been conflating "Rust is hard to learn" with "Rust isn't worth learning for web services." Those are different problems. One is about me. The other is about what actually works at scale.

The Real Problem They Solved: Predictable Performance Under Load

Most web developers talk about speed in abstract terms. But MandarinClips exposed something I see constantly in my own work: garbage collection pauses and unpredictable tail latencies are real killers when you're serving thousands of concurrent users with sub-millisecond search expectations.

With a Rust backend using Axum and Tokio, they eliminated garbage collection entirely. On a tiny 2-core VPS, they're handling thousands of concurrent requests with zero GC pauses. That's not flashy. It's boring. But boring is exactly what production needs.

I've debugged Node services where a GC pause spikes response times from 10ms to 200ms. It's maddening because your code is fine—the runtime is just cleaning house. Rust forces you to think about memory ownership upfront, which means your deployment doesn't surprise you at 3am.

Database Indexing: Where Most Developers Leave Money on the Table

Here's where I got genuinely interested. They indexed 100k+ Chinese clips with PostgreSQL trigram (pg_trgm) GIN indexes for sub-millisecond fuzzy search. This isn't novel in isolation, but the execution is clean.

CREATE EXTENSION pg_trgm;
CREATE INDEX idx_clips_text_zh_trgm ON clips USING GIN (text_zh gin_trgm_ops);
CREATE INDEX idx_clips_pinyin_search_trgm ON clips USING GIN (pinyin_search gin_trgm_ops);

The insight here is they indexed both the original Chinese text and the romanized pinyin. A learner searching "ni hao" should match "你好" just as quickly as someone searching the Chinese directly. Most developers would either build a second search table or accept slower queries. They built the right data structure.

I've seen teams throw Elasticsearch at search problems when PostgreSQL GIN indexes would have been faster and cheaper. Not always—Elasticsearch has its place. But I think we've collectively forgotten that Postgres is good at searching if you index correctly.

The Bandwidth Play: Making Economics Impossible to Ignore

They're serving 100k video clips. Video bandwidth is a budget-destroyer on AWS or GCP. So they stored everything on Backblaze B2, proxied through Cloudflare, and got zero-cost egress thanks to the Bandwidth Alliance.

This is where I'd normally roll my eyes at "optimization theater." But the math is real: they eliminated their biggest operational cost while actually improving performance because Cloudflare's edge network serves cached assets faster than their origin VPS ever could.

Most developers never question their cloud provider's default storage solution. I certainly haven't when I'm just shipping something quickly. But at scale, this kind of thinking—"what's the actual cost lever here and can I move it?"—is how you avoid surprise bills.

What I'd Actually Do Differently

I'm not entirely sold on Rust for every web service. Their backend is primarily handling search requests and quota tracking—stateless, compute-bound work where Rust shines. If they were building a complex state machine with lots of database transactions, I'd probably still reach for Go or TypeScript.

Also, they migrated from underscore to dash URLs and used Next.js native redirects for 308 permanence. Smart. But I noticed they didn't mention caching strategy at the application layer. With 100k clips, are they caching search results? Warming indexes? That feels like the next frontier for their performance story.

My bigger question: how much of their performance win comes from Rust's safety, and how much just comes from not using a language with overhead? A Go service would probably hit 95% of these benchmarks with half the learning curve. That's worth thinking about.

The Real Takeaway

This project convinced me that Rust belongs in my toolkit for specific problems: high-concurrency, latency-sensitive backends where predictability matters more than iteration speed. Not for everything. But for something. And that's worth my time.

Source: This post was inspired by "How I built a high-performance Chinese learning platform with 100k+ TV clips using Rust and Next.js 15" by Dev.to. Read the original article