Optimizing VPS for 'Bun + Hono + Turso' to Hit 100k+ Req/Sec: The Ultimate Node.js/Express Alternative for Flash Sale Campaigns
Introduction: The Limitations of Legacy Stacks in High-Concurrency Scenarios
For years, the standard blueprint for building scalable web applications has relied heavily on the classic combination of Node.js and Express. While this ecosystem boasts maturity and a vast community, it increasingly struggles under the extreme, sudden spikes of modern web events like e-commerce Flash Sales. When hundreds of thousands of users attempt to access a limited inventory simultaneously, the overhead of the Node.js runtime and the middleware architecture of Express can quickly lead to bottlenecked event loops, high memory consumption, and ultimately, dropped connections.
To survive modern concurrency demands without inflating cloud infrastructure costs, engineering teams need a paradigm shift. Enter the modern powerhouse stack: Bun (the ultra-fast JavaScript runtime), Hono (the lightweight, web-standards-compliant framework), and Turso (the distributed SQLite database built on libSQL). This article explores how to architect, configure, and optimize a standard Virtual Private Server (VPS) leveraging this stack to break the barrier of 100,000+ requests per second (req/sec).
---Why Bun + Hono + Turso? The Paradigm Shift
Before diving into optimization configurations, it is crucial to understand why this specific trio represents a generational leap forward from Node.js and Express.
1. Bun: Performance by Design
Unlike Node.js, which is built on Google's V8 engine, Bun utilizes the JavaScriptCore (JSC) engine developed by Apple for Safari. JSC is heavily optimized for fast startup times and lower memory usage. Furthermore, Bun is written from scratch in Zig, a low-level systems programming language. This enables native execution of many web APIs, integrated bundling, and an incredibly fast built-in HTTP server that bypasses the historical overhead associated with Node's http module.
2. Hono: Ultrafast and Lightweight Router
Hono (meaning "flame" in Japanese) is a small, exceptionally fast web framework built on top of web standard APIs. Unlike Express, which relies on complex routing logic accumulated over a decade, Hono utilizes a highly optimized RegExp Router. It avoids unnecessary allocations, boasts zero dependencies, and functions uniformly across Bun, Cloudflare Workers, and Node.js. In benchmark tests, Hono consistently handles routing operations significantly faster than Express.
3. Turso: Edge-Ready, Low-Latency Storage
In a flash sale scenario, the database is traditionally the primary single point of failure. Traditional relational databases like PostgreSQL or MySQL require heavy connection pooling and incur network latency overhead. Turso solves this by utilizing libSQL, an open-source fork of SQLite. It allows databases to be replicated or embedded closer to the application runtime, effectively eliminating massive network round-trip times and supporting highly concurrent, low-latency read operations.
---Kernel and OS-Level Optimizations for the VPS
Even the fastest runtime will choke if the underlying operating system limits network throughput. To achieve 100k+ req/sec on a Linux VPS (e.g., Ubuntu 24.04 LTS), we must modify system limits to handle massive volumes of concurrent TCP connections.
Increasing File Descriptors and Max Open Files
In Linux, every incoming connection is treated as a file. By default, systems restrict the number of open files per process, often to 1024. We must drastically increase these limits in /etc/security/limits.conf:
* soft nofile 1048576
* hard nofile 1048576
root soft nofile 1048576
root hard nofile 1048576
Tuning the Network Stack via sysctl
Next, we need to optimize the Linux kernel's network sub-system. Open /etc/sysctl.conf and append the following configurations to handle rapid connection reuse and increase buffer sizes:
- net.core.somaxconn = 65535: Increases the maximum backlogged socket connections queue.
- net.ipv4.tcp_max_syn_backlog = 65535: Higher limit for half-open connections during a traffic surge.
- net.ipv4.tcp_tw_reuse = 1: Allows the kernel to safely reuse TIME_WAIT sockets for new connections, preventing port exhaustion.
- net.ipv4.ip_local_port_range = 1024 65535: Expands the available local port range to maximize outgoing/reverse-proxy connections.
- net.core.rmem_max and wmem_max = 16777216: Allocates larger OS-level buffers for TCP read and write operations.
Apply these changes immediately using the command: sudo sysctl -p.
Application Architecture & Code-Level Optimization
With the operating system prepared, the code must be structured to ensure zero blocking operations. Hono's minimalist footprint allows us to write highly performant endpoints.
Efficient Memory Management and JSON Parsing
Bun handles JSON serialization natively at native-code speeds. When writing Hono endpoints, avoid cloning objects unnecessarily and rely on direct streaming or optimized schemas. Below is an optimized architectural pattern for a highly concurrent flash sale checkout endpoint:
import { Hono } from 'hono';
import { createClient } from '@libsql/client';
const app = new Hono();
const turso = createClient({
url: process.env.TURSO_DATABASE_URL,
authToken: process.env.TURSO_AUTH_TOKEN,
});
// Pre-compile schema validation or cache lookups if possible
app.post('/api/v1/flash-sale/checkout', async (c) => {
try {
const body = await c.req.json();
const { itemId, userId } = body;
// Execute transactional logic via Turso libSQL
const result = await turso.execute({
sql: "UPDATE inventory SET stock = stock - 1 WHERE id = ? AND stock > 0 RETURNING id",
args: [itemId]
});
if (result.rows.length === 0) {
return c.json({ success: false, message: 'Item out of stock' }, 422);
}
return c.json({ success: true, orderId: crypto.randomUUID() }, 200);
} catch (error) {
return c.json({ success: false, error: 'Internal Server Error' }, 500);
}
});
export default {
port: 3000,
fetch: app.fetch,
};Leveraging Turso's Embedded Replicas
To minimize the database connection bottleneck, utilize Turso's embedded replicas feature. By configuring Turso to sync a local SQLite database file on the VPS storage directly, read queries execute locally at microsecond latencies, while write operations are securely synced back to the primary database asynchronously or via transactional state synchronization. This setup effectively removes the network layer entirely from stock-checking queries.
---Deploying and Clustering Bun for Maximum Throughput
To fully saturate a multi-core VPS server, Bun applications should be run in a clustered manner. Unlike Node.js, which heavily relies on PM2 (adding significant overhead), Bun can be run effectively using its native multi-threading capabilities or orchestrated cleanly via lightweight systemd services paired with an ultra-high-performance load balancer like Nginx or Envoy.
Configuring Reverse Proxy with Nginx
When placing Nginx in front of Bun, ensure Nginx is configured to use HTTP/1.1 and keep-alive connections to prevent overhead on backend sockets:
upstream bun_cluster {
server 127.0.0.1:3000;
keepalive 64;
}
server {
listen 80 default_server;
location / {
proxy_pass http://bun_cluster;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}Conclusion and Benchmark Summary
By migrating from Node.js/Express to Bun + Hono + Turso and tuning the Linux kernel parameters, a standard, cost-effective VPS can comfortably scale to sustain over 100,000 requests per second. This paradigm shift dramatically lowers infrastructure expenditure while ensuring that your application remains responsive during critical flash sale windows. The era of over-provisioning massive cloud clusters simply to compensate for legacy runtime inefficiencies is officially over. Embrace the modern JavaScript stack and maximize your application's full performance potential.