Problem
What needed solving
Before mobile internet took hold, travel agencies across China relied on weekly printed DM (direct-mail) magazines to share pricing and itineraries. The format had two structural problems: poor timeliness (prices often shifted before the magazine arrived), and information silos (no agency could see nationwide pricing at once). The challenge was further compounded by extreme operational scale — 25 provincial branches publishing 200–300 pages each, all needing to go live within a 48-hour weekend window.
Approach
How I built it
Designed and built an end-to-end automation pipeline that turned uploads into a filesystem convention rather than manual data entry. The import tool walked a standardized directory tree, parsed metadata into the database, renamed high-res files by primary key, and distributed them across a file server cluster. Sharded by province for parallel ingestion, with full read/write path separation. The frontend reader was hand-rolled in jQuery, supporting tiered loading and CSS-transform-based zoom and pan for dense pricing tables — years before mature open-source alternatives existed.
Outcome
What happened
Ran stably for 10 years under high-load weekly publishing cycles. The 48- hour ingestion window consistently absorbed 5,000–7,500 high-res images across 25 branches; cumulative storage exceeded 1TB. The automation pipeline collapsed what would have required dozens of operations staff per branch into a standardized programmatic workflow. The platform was the primary nationwide channel for B2B travel pricing until it was retired in 2019, as mobile internet and vertical SaaS absorbed the intermediary role it had served.
This is a ten-year retrospective on a project that ran from 2009 to 2019 and was shut down as the pandemic and mobile-internet shift reshaped the travel industry. The full write-up — including the engineering decisions, the indexing lessons learned the hard way, and what I'd do differently today — is in the blog post linked from this page.
What this project was
A B2B platform that digitized weekly travel DM (direct-mail) magazines for 25 provincial branches across China. Every week, each branch published a 200–300 page magazine packed with tour pricing, itineraries, and departure dates. This platform took those magazines online so any travel agency in the country could browse the latest pricing in real time.
The real challenge: volume and window
The technical shape of the project was defined by two extremes:
- Volume. 5,000–7,500 high-resolution print-quality images per week, cumulative storage over 1TB.
- Window. All 25 branches finalized design on Thursday/Friday and had to be fully digitized and live by Sunday — a 48-hour weekend ingestion window with zero tolerance for missing pages.
Manual upload was a non-starter from day one. The entire system was built around the principle: keep humans away from the servers.
The automation pipeline
Four key design decisions formed the backbone:
- Directory structure as protocol. Operations organized files into a standardized hierarchy (province / issue / page); the import tool walked the tree and wrote metadata directly to the database. Convention over configuration, before I had the vocabulary for it.
- Files renamed by database primary key. Physical filenames on disk became plain integer IDs. This kept business semantics out of the storage layer and let database indexes run cleanly on integer PKs — a fix that came after performance had already slapped me once.
- Distributed storage with pipelined distribution. Province-sharded ingestion ran in parallel across a file server cluster. Each pipeline stage retried independently; failures didn't roll back entire batches.
- Hand-rolled jQuery reader. Tiered image loading plus CSS-transform- based zoom and pan, supporting the dense pricing tables travel agents needed to read. Built years before mature open-source equivalents existed.
Why it ran for ten years
In hindsight, the tech stack wasn't what kept it alive — the architectural constraints were. Filesystem conventions absorbed the most fragile part of the human workflow. Province-level sharding made peak-window load horizontally scalable by default. Read/write path separation meant production traffic was never at the mercy of the operations-side upload surge.
Common-sense decisions today. Each one earned the hard way back then.
What I'd do differently
Honest reflections from a decade later:
- ASPX became a liability. Every later integration had to work around it. A 2014 rewrite to Web API + decoupled frontend would have made the next five years much easier.
- Too much built in-house. Especially the frontend gesture interaction layer — mature alternatives existed by 2013, but "it works" kept us from revisiting it.
- Vertical scaling on SQL Server strained hard by the later years. I underestimated read/write separation and sharding approaches and missed the best refactor window.
- Monitoring was effectively non-existent. Issues were often reported by operations staff calling in. Unacceptable today.
Closing thought
The platform wound down in 2019. Partly the pandemic, partly something deeper: mobile internet had absorbed the intermediary role this platform played. DingTalk groups, WeChat groups, and vertical SaaS made a "magazine-online" platform structurally unnecessary.
It wasn't defeated. It was outgrown by its era. Something served the ten years it was built to serve, witnessed an industry's transformation, and exited with dignity — already a better ending than most engineers can expect.
For the full retrospective with technical details, see the linked blog post.
