Incremental Update Practices and Go‑Based Performance Optimization at Meituan Finance

Meituan Finance’s rapid growth exposed a problem: many users download static resources (JavaScript, CSS) over weak networks, causing higher failure rates and user churn. Reducing the size of each release improves load success and conversion.

Two main optimizations are proposed: more efficient caching and incremental updates that shrink the payload of each deployment.

How incremental updates work

The client‑side SDK (Thunder.js) reads the latest version number from the page and from localStorage. If they match, the cached file is used; otherwise Thunder.js requests an incremental patch from the server.

The server compares the old and new files using Myers’s diff algorithm, producing a tiny DSL patch consisting of three commands (retain, delete, insert). For example, converting "abcdefg" to "acdz" yields: =1 -1 =2 -3 +z Where \t separates commands, = means retain, - delete, and + insert.

Performance bottlenecks with Node.js

Node.js’s event‑loop model handles I/O well but struggles with CPU‑intensive diff calculations. In practice, computing a patch for a 200 KB file could take from tens of milliseconds to dozens of seconds, and the service faced >100 QPS with occasional spikes.

Three language‑level solutions were evaluated:

Node.js Addon (C/C++ native code)

ASM.js (deprecated)

WebAssembly

None reduced the patch‑generation latency to the millisecond level, and they would still block the main thread.

Switching to Go

Go offers higher raw performance (using go-diff instead of the Node diff package) and a lightweight concurrency model (goroutines) that better suits mixed CPU‑I/O workloads.

Benchmarking showed Go consistently outperformed Node.js on identical files, especially when the diff size was large.

Go’s concurrency uses many lightweight goroutines rather than a single event loop, allowing better CPU utilization under load.

Architecture redesign

The new system is split into three layers:

CDN – caches both full files and generated patches.

API layer – serves cached patches, falls back to full files if the compute layer is unavailable, and handles request aggregation.

Compute layer – performs diff generation; it is protected by rate‑limiting and can be degraded to full‑file responses when overloaded.

Additional mechanisms include pre‑warming tools that generate patches before a release and multiple CDN providers for redundancy.

Disaster recovery

Four failure categories are mitigated: network, storage, CDN, and compute. Each layer has local caches, and a separate CDN stores full files as a last‑resort fallback for the client SDK.

Results and lessons

After deployment, daily incremental‑calculation success reached 99.97 % with a 64.91 % share of updates being incremental, saving ~164 KB per user per day. Key takeaways:

Choose the right tool for the right job; changing language is justified when it solves a specific bottleneck.

Language solves local problems, architecture solves system‑wide issues.

Design for failure: anticipate bottlenecks and provide graceful degradation.

Lightweight concurrency (goroutines) can handle mixed workloads better than a single‑threaded event loop.