My Four Years at QQ Mail

It’s been over four years since I started working—time flies. I was fortunate to land a great opportunity right after graduation. Tencent’s Guangzhou R&D Center had just been established in July 2005, primarily focusing on Tencent’s email services. I joined the team in February 2006, and thus witnessed the entire evolution of QQ Mail. Some memories have faded over time, so details and timelines might not be entirely accurate, but I’ll do my best to recall.

Writing this series is a way for me to look back and summarize the past four years. I’ll share it from a personal perspective, not aiming for broad insights, but rather in a straightforward storytelling manner. I’m someone with few stories, yet I love telling them.

You might have heard the story behind Tencent’s email venture. The initial team was overly confident, believing that placing the email service inside the QQ client and leveraging QQ’s massive user base would naturally lead to success. But the opposite happened. Realizing the mistake, Tencent urgently launched a web version of QQ Mail in 2004—QQMail 2.0. However, this version was clearly rushed and fell far behind competitors like NetEase. In mid-2005, Tencent acquired Foxmail and its team, forming the Guangzhou R&D team dedicated to QQ Mail’s development and operations. It was evident that the company now placed high strategic importance on email, effectively acknowledging earlier misjudgments. This decision laid the foundation for QQ Mail’s future success.

In the world of software, successful products often have a key figure behind them—and QQ Mail is no exception. The pivotal person here is well known: Allen Zhang (Zhang Xiaolong), the creator of Foxmail. In 2009, Lai Yonghao mentioned in a technical discussion several top Chinese programmers and their iconic software: Qiu Bojun with WPS, Bao Yuelou with UCDOS3, Wang Jiangmin with KV100, Liang Zhaoxin with Super VCD 3, Zhang Xiaolong with Foxmail, and Hou Yantang with FlashGet. Zhang is considered a leading figure among China’s second-generation programmers. Though once a top-tier developer, he didn’t guide QQ Mail as a technical lead. If there’s one role that best describes him, it’s product manager. Zhang once published an internal article sharing his views on internet team management, arguing that managing a team isn’t about managing people, but about managing product experience. With product experience at the core, both design and development teams grow together with the product. His influence on QQ Mail is akin to Steve Jobs’ impact on Apple.

QQ Mail 3.0 was the first email product independently developed by the Guangzhou team. Version 2.3 was inherited from headquarters, and much of 3.0’s backend code was also carried over from 2.3. The 3.0 UI resembled a hybrid of Hotmail and Outlook—the idea was clear: bring the desktop email client experience to the web, creating a rich web-based email application. At the time, the first tier of Chinese email services included NetEase and Yahoo China (Yahoo China came later), while the second tier consisted of Sina, Sohu, TOM Online, and 21CN. The third tier included independent email providers. We often checked rankings on iResearch, and QQ Mail was around 12th place—outside the top three tiers, with a market share nearly negligible. Our goal then was simply to enter the second tier within one or two years. If someone had said back then that we’d surpass NetEase to become the market leader, no one would have believed it—not even us.

QQ Mail 3.0 was Guangzhou R&D’s debut product. We poured all our manpower and resources into it, adopting the most advanced technical architecture and top-tier UI design available at the time. It innovatively used Outlook’s three-pane layout, closely mimicking a desktop email client. This was an early attempt at software-as-a-service.

I joined Guangzhou R&D in February 2006, by which time 3.0 had passed its most intense development phase and entered limited public testing—users could switch between 2.3 and 3.0. The core development of 3.0 lasted about six months. When Guangzhou R&D began hiring in mid-2005, most engineers lacked prior experience in email product development. We were learning as we went. Despite this, the team adopted cutting-edge AJAX technology. The JavaScript code had a strong object-oriented flavor, and the entire web framework was built using traditional software engineering principles. From a development process standpoint, nothing was wrong—but the product had a major flaw: it was slow. Not just a little slow—extremely slow. Only users on fast telecom networks could log in smoothly; others were stuck at the login screen. For most of 2006, the entire team focused on solving performance issues. We halved the JS file size, minified and obfuscated the code, and split JS files into smaller chunks. But none of these brought fundamental improvement—users still found it too slow. Looking back, I believe that merely compressing or splitting JS files couldn’t solve the root issue: the logical architecture of the JavaScript itself. The code used a clear class inheritance structure, which wasn’t suitable for physical file splitting. Even when split, the rendering overhead remained unchanged.

The 3.0 backend was largely a mix of inherited and open-source code. The core email delivery module used Postfix, one of the best available engines at the time, while the web frontend relied on Apache. Email storage used a simple single-file approach, and user data was stored in a basic way—account info and mail lists were stored together. This architecture was sufficient for the user scale at the time.

Before 2006, the Guangzhou team working on QQ Mail development and operations was small. That year, we hired many fresh graduates—I was among the first batch. At the time, 3.0 development was mainly handled by two groups: the QQMail team and the System Architecture team. On paper, the QQMail team focused on product development, while the Architecture team handled backend research and development. But in practice, the distinction was blurry—both teams worked on frontend and backend development, likely due to staffing constraints. The QQMail team also managed product operations and had slightly more members. I joined the QQMail team as an intern, working on various tasks: writing CGI scripts, building internal tools, and doing statistics. Most of my time, however, was spent reading code—the aforementioned JavaScript, backend, and CGI code. Those three months were the most energetic period of my life. I reviewed all the code, filled several notebooks, and now, looking back, it still feels incredible.

The QQMail team was led by Ted, and the System Architecture team by Harvey. Both had a profound impact on me. I later worked under each of them for two years, learning a great deal and receiving many valuable opportunities.

Ted was primarily responsible for QQ Mail’s product development and operations. When I joined, 3.0 had moved past intensive development and entered optimization mode, with higher demands on operational quality. At the time, QQ Mail’s operations relied on a basic data statistics system and Nagios. Data collection and analysis were simple: CGI wrote logs, which were then collected and processed using shell scripts for database import—even the data dashboards were generated via shell. Ted assigned Aoger as my mentor. I worked with Aoger to get familiar with the system and began experimenting with data statistics, occasionally writing product CGIs. Aoger was an incredibly patient mentor, especially with someone like me who asked endless follow-up questions. He gave me the most support in those early days. Without him, I couldn’t have grasped QQ Mail’s entire architecture in just three months. For questions Aoger couldn’t answer, he’d refer me to others—but I often took the shortcut and went straight to Ted :). These interactions helped build mutual understanding, laying the groundwork for Ted to give me timely and meaningful opportunities later. But above all, it was Ted’s trust that mattered most.

After working with Aoger on operational monitoring and related statistics systems, Ted gave me my first independent project: the Guangzhou R&D business data system. This system included data collection, processing, analysis, report visualization, and alerting for data fluctuations. It’s still in use today, with the backend architecture largely unchanged. Through this project, I mastered two new languages: shell and Python—enough to build full systems with either. I’m grateful to Felix for his help with shell scripting, and to Vincent for introducing and supporting me in Python. Both were experts, fluent in their craft. Shell allowed me to master automated data collection—end-to-end pipelines for collection, error handling, and alerts, with clean, readable code (please allow me a moment of pride). Python became a language I deeply loved, captivating me for two years—I even read books analyzing Python’s source code last year. I used Python to build internal web interfaces, generating reports, charts, and trend graphs. My proudest achievement was designing a lightweight template language in Python. With simple configurations, it could generate statistical pages and extract data effortlessly. It’s still used by colleagues today, and the code remains clean (yes, I’m proud again).

A competent programmer never settles for repetition. Though I later took on many internal system projects—each of which could have been done by copying and tweaking the previous one—I made each one unique, ensuring at least one new innovation per system. Ted later had reason to say I was too immersed in technology and neglected organizational skills. Still, he trusted me and gradually involved me in product development. This time, I nearly single-handedly built QQ Mail’s self-service system, including FAQ search, recent login history, recent send/receive records, and recent deleted emails. This was my first backend service, and it proved highly stable. Its backend later became the foundation for the email sending status query service, which still runs today. Thanks to this success, Allen Zhang transferred me to the Architecture team to work on the “Reading Space” project. Though I personally consider that service my worst, it was highly significant. It’s a testament to how internet development is driven by results, not process.

Although I gained substantial experience and achieved some success in 2006, QQ Mail was still struggling with the trade-off between speed and features. Internally, Tencent was running the “Hummer” project—Guangzhou R&D was tasked with building another email product, HummerMail, alongside QQ Mail. To support this, the Architecture team completely restructured the backend: the user data storage module was transformed into a more generic storage service. This service later became Guangzhou R&D’s most critical backend, supporting data storage for most user-facing features. Account information was decoupled into a standalone account system. Due to the importance of new mail notifications, a dedicated backend was built to ensure real-time, reliable alerts. Although this refactoring couldn’t save QQ Mail 3.0 from failure or prevent HummerMail from being canceled (a story for another time), it became the core backend for the next-generation QQ Mail. It was a remarkable overhaul—one that deserves a place in history.