Designing a Scalable Backend for One Billion Users with Minimal Resources

Assuming 20 million daily requests are evenly distributed over one hour (3 600 seconds), the peak concurrency is less than 10 000 requests per second.

If the dataset contains 1 billion records (≈1 G entries) and each record occupies 16 bytes (e.g., a 48‑bit integer for an ID plus additional fields), the total size is about 16 GB, which fits comfortably in modern server memory.

With a personal PC of 32 GB RAM, a server with 256 GB or even 1 TB memory has been commonplace for many years.

Data can be sharded across multiple servers based on the first 3 or 6 digits of the ID (regional code), automatically dispatching a request to the appropriate province’s server.

Thus each server only needs to store 100‑200 million records; twenty 16 GB virtual‑machine instances provide ample capacity.

System startup proceeds as follows:

1. Load all records belonging to the server (200‑400 million rows) from the database – a relatively slow step.

2. Begin serving requests.

Even under the worst‑case scenario of 20 million accesses within one hour, the system only needs to serve about 5 556 users per second.

At 2 KB of response data per user (1 KB is already generous unless generating QR codes on the server), the per‑second data volume is under 12 MB.

The service is a short‑link lookup: TCP handshake, send the ID, receive the data, and close the connection.

Therefore, the classic C10k problem is not a concern; on Windows use I/O Completion Ports, on Linux use epoll, or write a cross‑platform program with libevent. A 100 Mbps link per server is sufficient.

Searching the ID in an array can be O(1) with a direct index; using binary search yields O(log N), which for 1 billion entries requires at most 30 comparisons. In‑memory lookup latency is negligible compared to network latency.

In short, no special technology is required: twenty 16 GB VMs, simple array or binary‑search access, and a 100 Mbps outbound link can comfortably support 20 million hourly queries for a billion users.

With a total of 1 Gbps bandwidth, the system could serve 200 million users per hour; if each VM has 100 Mbps outbound, the cluster already covers nationwide demand.

Of course, real‑world reliability must be considered. Unstable VMs or buggy code could cause failures.

Additional standby VMs managed by Zookeeper can take over instantly if a node fails.

Data updates (e.g., nucleic‑acid test results) do not need real‑time freshness; a one‑hour delay is acceptable. A database trigger can push changes to all nodes.

Advertisement: If you need a legitimate JetBrains All‑Products Pack, contact me – 56 CNY per year, official license, details on the website, WeChat: poxiaozhiai6 (note: 910).

Having worked in similar companies, I know the client side often lacks technical depth.

Consequently, a "large", "complex", "unprecedented" system could be delivered with just a few thousand lines of C and JavaScript code – will the client actually pay for it?

It's not about whether the client understands; it's about how much you can charge for a handful of lines and still justify the expense.

Therefore, from the start, avoid letting programmers over‑engineer; otherwise, the project becomes overpriced.

The simplicity of the solution means even a mediocre team can deliver it, perhaps by buying extra servers or tolerating more incidents, which paradoxically makes the spending look justified.

In my experience, a colleague once reported that my code was too short – I completed a feature in 300 lines (including 50% comments), which allegedly caused significant loss for the company.

Faced with such contradictions, I chose not to resign and kept working.

Original source: zhihu.com/question/551451538/answer/2667817410 Author: invalid s