Stripe Architecture Deep Dive: Rust (Axum + SQLx) vs Go (sqlc) for Billing Systems

Forum topic · 小凯 · 2026-01-24

Summary

This forum post analyzes the architectural evolution of a Stripe-style billing system, arguing for Rust (Axum + SQLx) over Go (sqlc) in high-concurrency payment infrastructure. At billing scale — 10M+ requests per second, sub-millisecond latency targets, retry-induced connection storms, and daily schema changes — the author contends that sqlc's code-generation workflow becomes a hidden tax: every schema change requires regeneration, full rebuild, and redeployment, while struct mapping and goroutine scheduling overhead strain connection pools under load. The proposed Rust stack uses Axum routing, Tower middleware (auth, rate limiting, tracing), SQLx async prepared statements with cached query plans and compile-time SQL checking, and Postgres with JSONB plus generated columns for zero-downtime schema evolution, fronted by PgBouncer and read replicas. Cited load-test results (10K concurrent, wrk2) claim roughly 3x higher throughput, P99 latency of 0.6ms vs 1.9ms (-68%), and memory reduction from 4.2GB to 1.6GB, with stable connection pools and no thrashing under simulated 50K req/s bursts. The post outlines a 60-day migration roadmap covering SQLx fundamentals, Axum CRUD APIs, schema evolution strategy, and production load testing, and positions these skills as high-value for engineers building resilient payment systems.

Stripe Architecture Deep Dive: Why Rust (Axum + SQLx) Beats Go (sqlc) for Billing Systems

*Translation and summary of a Chinese tech-forum post analyzing billing-system architecture at Stripe scale. Claims below are from the original post, based on an attributed 2026 report by Dagger.*

Background: This Is Not Toy CRUD

The post argues that a Stripe-style billing system faces extreme real-world constraints:

10M+ requests per second — unpredictable traffic spikes and webhook floods
Sub-millisecond latency targets with strong consistency requirements
Retry storms — failure retries can instantly collapse fragile connection pools
Constant schema churn — metadata, indexes, and fields change daily

The Conflict: The "Hidden Tax" of Go sqlc

While sqlc's type safety is pleasant in small projects, the author argues it becomes operational hell in a frequently changing billing system:

Go + sqlc cycle (pain points): 1. Schema change (add column / change index) 2. sqlc generate (code regeneration) 3. Full binary rebuild 4. Redeploy & restart (service interruption risk)

Consequence: under high concurrency, struct-mapping overhead grows, goroutine scheduling pressure increases, and connection pools can crash.

Rust Axum + SQLx advantages:

No codegen — schema changes don't require full binary rebuilds; bottlenecks are solved at runtime rather than compile time
Async prepared statements — pool.prepare_cached() automatically reuses query plans; SQL is checked at compile time, results extracted at runtime
JSONB + generated columns — Postgres features enable zero-downtime schema evolution

Benchmark Results (Billing API CRUD, 10K concurrency)

| Metric | Rust (Axum + SQLx) | Go (sqlc) | Delta | |---|---|---|---| | Throughput | ~3x baseline | baseline | +3x | | P99 latency | 0.6 ms | 1.9 ms | -68% | | Memory (after migration) | 1.6 GB | 4.2 GB | -62% | | Connection pool under 50K req/s burst | Stable, no thrashing | Thrashing | — |

Load testing was performed with wrk2 at 1M+ RPS targets.

The Production Stack Blueprint

1. Axum Routes — /invoices, /customers 2. Tower Middleware — auth, rate limiting, tracing 3. SQLx (async) — prepared statements, connection pooling 4. Postgres + JSONB — read replicas, PgBouncer

60-Day Migration Roadmap

Weeks 1–2: SQLx async foundations — async prepared statements, pooled transactions, understanding Postgres behavior over Rust syntax
Weeks 3–4: Axum CRUD — build Invoices/Customers APIs, integrate Tower middleware (auth, rate limiting)
Weeks 5–6: Schema evolution strategy — JSONB metadata, generated columns for query optimization, zero-downtime migrations without regeneration
Weeks 7–8: Load testing & launch — wrk2 benchmarks at 1M+ RPS, compare against legacy system (Fiber + sqlc); capstone: deploy a Stripe-style billing API on Fly.io

Conclusion

The author's thesis: engineers who choose Axum + SQLx well aren't paid for syntax knowledge but for avoiding real production incidents. Suggested resume highlights from the post:

Axum + SQLx billing API, 1.8M RPS, p99 < 1ms
sqlc → SQLx migration: memory 4.2GB → 1.6GB, 3x throughput

> Note: These figures come from the original forum post and its attributed source report; readers should treat the benchmarks as illustrative rather than independently verified.