Building a Large-Scale Transaction Platform: Architecture, Organization, and Lessons Learned

Introduction: The author, a senior engineer from a large domestic travel website, recounts the challenges of building a high‑availability transaction platform from scratch, addressing both technical and non‑technical issues.

Background : The project started with a vague idea and minimal resources—only one developer, one product manager, and one business person—driven by a commitment to the airline ticket division.

Development Organization : The team was assembled by borrowing developers from other departments, converting .NET engineers to Java, and dealing with issues such as inconsistent languages, varying skill levels, and staff stability. Management practices like daily stand‑ups, progress boards, and color‑coded status tracking were introduced.

Requirement Analysis : Due to insufficient product documentation, the engineering team helped refine the PRD, converting it into flowcharts, swim‑lane diagrams, and state‑machine models. Sequence diagrams were emphasized for clear communication of object interactions.

Data Modeling : A database schema was designed to handle an estimated 1,500 tickets per day, resulting in roughly 118,125 records per month. The model accounts for orders, work orders, replies, status changes, payments, flights, and passengers, leading to a decision to use database sharding without table partitioning.

Architecture Design : The system aims for stability, reliability, security, and flexibility. Existing policy‑management and search modules were reused, while new modules (pre‑sale, post‑sale, work‑order, operations) were added. The architecture uses Dubbo RPC, MyBatis for DAO, and a layered design separating public services, business logic, and external support.

Core Modules :

Flight Search : Queries are indexed in Solr, with policy details cached in Redis.

Order Creation (Booking) : After price verification ("核价"), the system proceeds to order creation, using a chain‑of‑responsibility pattern for extensible workflow handling.

Payment System : Supports multi‑step payments, refunds, interruption handling, detailed reporting, admin overrides, and third‑party integrations (Alipay, WeChat Pay). The design separates payment orchestration (blue module) from command composition (green module) and extension points (orange module).

Design Principles : The modules follow the Dependency Inversion Principle and Single Responsibility Principle, with a three‑layer structure and extensive service interfaces. Asynchronous processing is introduced via a custom thread‑pool design to improve throughput, acknowledging trade‑offs in complexity and resource usage.

Additional Architectural Concerns : Interface reuse, transaction rollback handling with @Transactional, file storage options (FastHFS), and local caching via CacheBuilder to reduce Redis load are discussed.

Implementation took roughly two months, followed by a stable release despite personnel turnover, market changes, and organizational restructuring.

Conclusion: The author hopes the sharing helps others facing similar large‑scale platform challenges and invites further discussion via WeChat.