Why Browser Clients Should Adopt Asynchronous Programming: An Actor‑Model Perspective

Chen Yehao, a senior architect in the cruise vacation division with over 15 years of software development experience, introduces his background in Python, open‑source technologies, and research on message‑passing asynchronous programming in multi‑core environments, including Erlang, Go, and F#.

He recaps earlier concepts: (1) asynchronous programming on a single machine boosts CPU utilization; (2) the Actor model ensures serial execution in concurrent environments, preserving transaction correctness; (3) combining the Actor model with Zookeeper enables serial operations across multiple servers; (4) read‑write separation allows a stateful write service to operate correctly while scaling a stateless read service for performance.

The focus shifts to why the consumer side—browsers—also needs asynchronous patterns. Historically, Erlang assumed unreliable network communication, providing only asynchronous calls and simulating synchronous behavior when needed, ensuring the runtime never blocks the CPU due to external operations.

In the modern Internet era, this assumption still holds: network and external services remain unreliable. Designing synchronous call architectures introduces significant risk, illustrated by a typical e‑commerce order flow: browser → web server → application server (checks inventory, locks stock, creates order) → web server → browser.

Step 3 (inventory check and order creation) often exceeds one second, becoming a bottleneck. If step 2 (web server → application server) cannot be asynchronous, the web server blocks, dramatically reducing throughput.

The article then rewrites the order process to simulate synchronous behavior with asynchronous calls: the application server immediately returns an order ID, processes inventory in the background, and the browser polls the server via Ajax every two seconds until the order status becomes “success,” at which point it redirects to a confirmation page.

In this asynchronous flow, the inventory‑checking task (step 3b) runs in parallel with the browser’s polling (step 4). Thanks to the earlier read‑write separation design, the write service handles the order creation while the read service serves the polling requests, allowing independent optimization.

Using asynchronous browser access splits a single time‑consuming request (“place order and wait for result”) into two lightweight requests: one to place the order and another (potentially repeated) to query the result, leading to faster responses from both the web and application servers.

Even legacy web servers that lack native asynchronous capabilities can benefit from this pattern, as it eliminates blocking when communicating with the application server.

In high‑concurrency scenarios, modeling state‑changing operations (e.g., refunds) as asynchronous processes is optimal, reducing system pressure. When synchronous interaction is unavoidable—such as immediate order confirmation—designing it as an asynchronous simulation still prevents browser timeouts and enables separate tuning of read and write services. Additionally, Ajax polling allows the browser to display animations, improving user experience.

Finally, while Ajax polling is a practical fallback for browsers, environments where the server can actively push results to the client should prefer callbacks, as they avoid the overhead of repeated polling.