14 Years of Engineering Lessons: What Building Dida Holdings Taught Me

Becky_dev — Thu, 13 Aug 2026 02:15:37 +0000

In 2012, I joined a small travel technology company called Dida Travel. Nobody knew the name. We had maybe twenty people, an office in Beijing that smelled like instant noodles, and a belief that we could fix how Chinese travelers accessed the world.

Fourteen years later, that company had processed over twelve billion dollars in travel bookings. We had teams in eight countries. We were serving fifty million travelers a year. And I had learned more about building things the hard way than any MBA could teach me.

This is the story of what went wrong, what went right, and why I’m now building RollingGo.

The First Mistake: Building Everything Ourselves
When we started, the problem seemed simple. Chinese travel agencies had no reliable way to book hotels outside of China. The big OTAs — Ctrip, Qunar — dominated domestic travel. But international? That was a mess of phone calls, emails, and handshake deals.

We thought we could build the solution ourselves. Direct integrations with every hotel chain. Custom booking engines. Payment processing with fifteen different providers. An internal CRM for customer service.

By 2014, we had forty-seven engineers maintaining twenty-three different systems. Nothing talked to each other. A deployment took six hours. We were drowning in our own code.

The turning point came when our CTO quit. Not dramatically — he just walked into my office one Friday and said, “I can’t do this anymore. Every time we add a feature, three things break. We’re not building a company. We’re building a museum of bad decisions.”

So we made a choice: stop being a technology company and start being a distribution company. Instead of building direct integrations with every hotel, we partnered with existing aggregators — Hotelbeds, WebBeds, TUI. We focused on what actually mattered: pricing intelligence and booking optimization. We let our partners handle the messy supplier relationships.

Engineering headcount grew twenty percent. Inventory grew four hundred percent. Sometimes the best code is the code you don’t write.

The Black Friday That Almost Killed Us
November 2015. We had just launched a major promotion with one of China’s biggest OTAs. On day one, we processed ten thousand bookings. The system handled it fine. Day two brought fifty thousand bookings. The database started slowing down. Day three brought two hundred thousand bookings. And everything caught fire.

Our monolithic booking engine had no sharding. No queues. No caching layer. Every query hit the database. Every supplier failure took down the whole system.

We spent seventy-two hours straight fixing it. We implemented read replicas. We added Redis caching for inventory searches. We built async queues for booking confirmations. We deployed circuit breakers for supplier APIs.

The system survived. But the lesson stuck: scale isn’t about handling normal load. It’s about surviving peak load. Your system is only as strong as its worst Black Friday.

The Debt We Couldn’t Escape
By 2017, we had three different booking engines running in production. Legacy, v2, v3. We had five different databases — MySQL, PostgreSQL, MongoDB, Oracle, SQL Server — because different teams had made different choices at different times. We had twelve caching layers. Twenty microservices, some well-designed, most not.

Every new feature required changes to four or five systems. Engineers spent sixty percent of their time maintaining old code. We talked about a ground-up rewrite. Eighteen months. Thirty engineers. Five million dollars.

We never did it. Instead, we built abstraction layers to hide the complexity. We slowly migrated traffic to newer systems. We killed legacy systems one at a time over three years. It was boring. It was frustrating. It worked.

Big-bang rewrites almost always fail. Incremental migration is boring but works.

Going International
Between 2018 and 2020, we opened offices in eight countries. Singapore as regional HQ. Bangkok for Thailand. Tokyo for Japan. Seoul, London, Dubai, Los Angeles, Sydney.

Each market was different. GDPR in Europe. PDPA in Singapore. Alipay in China. Credit cards in the US. Pix in Brazil. Twenty-four-seven support expectations in America. Email-only communication in Japan.

We learned that international expansion isn’t about translating your UI. It’s about rebuilding your operations for each market. What works in Beijing breaks in Berlin. What scales in Shanghai fails in São Paulo.

When Travel Stopped
March 2020. The world shut down. Overnight, our bookings dropped ninety-five percent. Cancellations exceeded new bookings ten to one. Suppliers demanded payment — we owed them fifty million dollars. Customers demanded refunds — we held thirty million of their money.

We negotiated payment deferrals with suppliers. We issued travel credits instead of refunds. We laid off forty percent of our staff. We pivoted to domestic travel. It was brutal. It was necessary. We survived.

Travel is the most fragile industry on earth. You don’t build for growth. You build for black swans.

Watching AI Fail
In 2024, I started seeing a pattern. AI agents were trying to book travel. And they were failing.

Every week, a new startup would announce their AI travel agent. “We built a travel booking agent!” “Our AI can plan your entire trip!” “Just tell it where you want to go!”

I tested them. They failed. No real-time inventory access. Cached pricing from days ago. Affiliate links instead of real bookings. No error handling for edge cases.

The problem wasn’t the AI. It was the infrastructure.

AI agents need real-time availability. Instant booking confirmation. Structured, machine-readable APIs. Error handling and fallbacks. They don’t need another search engine. They need a booking engine.

Why RollingGo Exists
RollingGo is the infrastructure layer I wish Dida had. We aggregate over a million hotels from fifty-plus suppliers. We provide real-time search and booking via MCP. We handle all the messy supplier integrations. We return structured, machine-readable responses. We support the full booking lifecycle — search, book, modify, cancel.

We’re free. No per-query pricing. No enterprise tiers. We do direct booking — no affiliate redirects. We’re production-ready — tested at Dida scale. We’re MCP-native — designed for AI agents from day one.

We’re not building another OTA. We don’t want your customers. We’re not building another affiliate program. We don’t do redirects. We’re not building another AI travel planner. We enable them. We don’t compete.

What I Learned
Don’t build what you can buy. Focus on unique value, not commodity features.

Scale for peak, not average. Your system is only as strong as its Black Friday performance.

Incremental beats big-bang. Boring migrations win. Heroic rewrites fail.

Distribution matters more than technology. Great tech with no distribution dies. Mediocre tech with great distribution wins.

International is hard. Don’t underestimate local complexity.

Cash flow kills companies. Profitability is vanity. Cash is reality.

Travel is fragile. Build for black swans, not just forecasts.

Partnerships compound. One good partner beats ten mediocre integrations.

Hire slow, fire fast. One bad hire costs ten times more than an open position.

Communicate ruthlessly. Over-communicate by ten times what feels natural.

Say no to almost everything. Focus is about what you don’t do.

Build for the next generation. Your legacy isn’t what you built. It’s what enables others to build.

The Next Chapter
The travel industry is at an inflection point. From 2012 to 2022, OTAs won. Centralized platforms — Booking, Expedia, Ctrip — captured most of the market. From 2024 to 2034, AI agents will win. Decentralized, agent-to-agent booking will dominate.

The winners will be infrastructure providers who enable AI agents. AI agents who deliver real booking capabilities. Suppliers who embrace direct API access.

The losers will be OTAs who can’t adapt. AI startups who build on broken infrastructure. Travel companies who wait for perfect conditions.

Dida Holdings taught me fourteen years of lessons. RollingGo is where I apply them.

If you’re building an AI travel agent, you have two choices. Spend fourteen years learning these lessons yourself. Or use RollingGo and stand on our shoulders.

We’ve open-sourced the infrastructure. The question is: what will you build?

DEV Community: Becky_dev

14 Years of Engineering Lessons: What Building Dida Holdings Taught Me