Public-service API sites have a distinct characteristic: a relatively small user base but a high volume of requests. A scenario with 1,000 users generating a million daily requests—averaging 1,000 calls per user per day—is quite normal. This is because users integrate your site into their own toolchains, performing automated polling and batch calls that far exceed the frequency of manual interaction.

The server requirements for this type of scenario differ completely from those of standard websites. While standard websites focus on page views (PV) and bandwidth, API sites prioritize QPS (queries per second), concurrent connections, and memory. Let’s start by quantifying the requirements and step-by-step determine the appropriate configuration.

First, accurately calculate the resources your site actually needs.

Many people choose servers based on intuition—thinking, "A million requests sounds like a lot, so I'll just buy a high-spec machine." The result is often either wasted budget from over-provisioning or a system crash during peak hours due to under-provisioning.

Step 1: Estimate peak QPS from daily request volume.

A million daily requests might seem to equate to 1,000,000 ÷ 86,400 seconds ≈ 11.6 QPS. However, this calculation is flawed. API traffic exhibits distinct peak characteristics; it is common for 80% of requests to occur within just 20% of the day.

Estimating based on this ratio: 1,000,000 × 80% ÷ (86,400 × 20%) ≈ 46 QPS. Furthermore, considering that users of public-service APIs tend to be most active in the evening, applying a peak multiplier of 2–3x brings the actual peak QPS to approximately 90–140.

Step 2: Estimate CPU requirements based on QPS.

API request processing logic is usually straightforward: receiving parameters, querying a database or cache, and returning a result. A single request typically consumes 5–15ms of CPU time. Taking a median value of 10ms, a single core can handle approximately 100 requests per second (assuming 75% effective utilization).

With a peak of 140 QPS, the required number of effective cores is approximately 140 ÷ 100 × 1.3 (redundancy factor) ≈ 1.8 cores. Accounting for traffic spikes and system overhead, 2 cores is the minimum starting point, while 4 cores offers a more comfortable margin. Step 3: Estimating Memory Requirements Based on Request Characteristics

Memory is the most common source of issues for API sites. Each TCP connection consumes approximately 1–2 MB of memory, while database connection pools, caches, and application processes also consume memory. With 1,000 concurrent users—assuming 200–500 simultaneously active connections—the connections alone require about 0.5–1 GB of memory. When factoring in the operating system, web services, databases, and caching, 4 GB is a reasonable baseline, while 8 GB provides sufficient headroom.

Step 4: Estimating Bandwidth Based on Request Body Size

Request and response bodies for public-service API sites are typically small—ranging from a few dozen bytes to a few kilobytes. Assuming an average request/response body size of 20 KB and a peak of 140 QPS, the outbound bandwidth requirement is approximately 140 × 20 KB × 8 ÷ 1024 ≈ 22 Mbps. However, considering that public-service APIs rarely return large files and many requests result in empty or extremely short responses, actual bandwidth needs are lower; 10 Mbps of dedicated bandwidth is sufficient.

Configuration Comparison by Concurrency Scale

Based on the estimation logic above, recommended configurations for sites of different scales are as follows:   

For a scenario with 1,000 users and one million daily requests, a configuration of 4 cores, 8 GB RAM, 10 Mbps dedicated bandwidth, and 100 GB SSD is the "sweet spot." This setup is "sufficient with headroom" for a public-service API site: under normal conditions, CPU utilization remains below 40% and memory usage stays around 3–4 GB, leaving ample capacity for traffic spikes.

More Important Than Configuration: Network Routing and Connection Capacity

Public-service API sites have a critical metric that is often overlooked: concurrent connection capacity. With 1,000 users, if each maintains 3–5 simultaneous long-lived connections (such as WebSockets or SSE streams), the system instantly requires 3,000–5,000 concurrent connections. Standard shared VPS plans often limit connections to just a few hundred or a thousand, creating a bottleneck that appears well before CPU limits are reached.

Network route selection is equally critical. Since the users of public-service API sites are almost exclusively domestic, using standard international routes causes packet loss during evening peak hours, sending API response times soaring from tens of milliseconds to several seconds. Packet loss impacts APIs more severely than standard websites; while browsers automatically retry lost packets for websites—making the experience feel merely "a bit slow"—API packet loss causes immediate request failure and triggers errors in the user's toolchain.

For API applications, the value of the CN2 GIA route lies not in "peak speed," but in "baseline stability." While packet loss on standard international routes can spike above 5% during peak hours, CN2 GIA keeps it under 0.5%. For API calls—where a single lost packet causes the entire request to fail—this difference directly determines service availability.

When selecting a provider, Jtti’s Hong Kong CN2 node is a strong contender. It features CN2 GIA direct connectivity across all three major carriers: China Telecom uses the dedicated 59.43 node, China Unicom uses AS4837, and China Mobile uses CMI; all three route traffic directly from Guangzhou to the Hong Kong data center. Real-world testing shows an average latency of 40–63ms across these carriers, with packet loss consistently remaining below 0.5%.

For requirements targeting a 4-core/8GB setup, Jtti’s Hong Kong flagship plan offers an 8-core/16GB configuration with 5Mbps of dedicated CN2 bandwidth for $48/month (after discount). For a scenario handling 1,000 concurrent user connections, the 8-core/16GB plan provides significantly more headroom than the 4-core/8GB option. If the budget is tighter, the 2-core/4GB standard plan ($29.36/month) serves as a viable starting point, allowing for upgrades later based on actual load.

Practical Migration: The complete process of moving from the old server to the new one

With the configuration selected, the next step is migration. The biggest concern when migrating a public-service API site is excessive downtime; user toolchains may aggressively retry upon disconnection, potentially triggering risk-control mechanisms.

Recommended approach: Parallel operation + DNS switching.

Step 1: Deploy the full environment on the new server. Set up the API gateway (e.g., New API, One API), database, and caching services, but do not switch the DNS immediately. Run both the old and new servers in parallel, with the old server continuing to handle live traffic.

Step 2: Import data to the new server. Export the database (using `mysqldump`) and configuration files from the old server and import them into the new server's database. If the data volume is large, compress the data on the old server before transfer to reduce transfer time.

Step 3: Conduct comprehensive API testing before the switch. Use `curl` on the new server to call key endpoints and verify correct responses. Simultaneously, use tools like `ab` or `wrk` to perform stress testing and confirm that the Queries Per Second (QPS) meet expectations.

Step 4: Switch the DNS. Point the API domain's A record to the new server's IP address. During the DNS propagation period (typically ranging from a few minutes to several hours), some users will access the new server while others still access the old one. Do not shut down the old server immediately; keep it running for at least 24 hours until DNS caches globally reflect the change.

Step 5: Post-migration system tuning. Once the new server is live, enable the BBR congestion control algorithm, adjust Nginx parameters such as `worker_connections` and `keepalive`, and tune the number of application processes based on actual load.

Recommendations for long-term maintenance of public-service API sites

Migration is merely the starting point. Operating a public-service API site requires long-term attention to several key areas.

Monitor peak QPS and connection counts, and set alert thresholds. If QPS consistently exceeds 70% of a single server's capacity, plan for upgrades or add additional nodes in advance. Regularly check the database connection pool; connection exhaustion is a common performance issue for API sites—since every request queries the database, an insufficient pool leads to queuing delays. Implement a robust backup strategy; although public-service sites rely heavily on configurations, user keys, API call logs, and routing rules require regular backups.

When selecting configurations for public-service API sites, the core logic is to "allocate resources based on peak demand and select network routes based on stability." For a scenario with 1,000 users and one million daily requests, a 4-core, 8GB configuration is a reasonable starting point, while an 8-core, 16GB setup allows room for growth. Regarding network connectivity, the advantage of low packet loss provided by CN2 GIA is far more valuable in API-driven scenarios than raw bandwidth figures alone. Visit the Jtti official website to view the full specifications and current promotional offers for Hong Kong CN2 cloud servers.