Securing High-Concurrency Ticket Sales: A Framework Based on Microservice
This paper presents a secure, high-performance railway ticketing system built on a Spring Cloud microservice architecture that effectively addresses high-concurrency challenges during peak periods while ensuring stability, data consistency, and a comprehensive online booking experience.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine a railway ticketing system as a massive, popular concert venue. During holidays, millions of people try to buy tickets at the exact same second. In the old days, the system was like a single, giant ticket booth with one clerk. When the crowd got too big, the line would freeze, the clerk would get overwhelmed, and sometimes, the clerk would accidentally sell the same seat to two different people because they couldn't keep track fast enough.
This paper describes a new way to build that ticketing system using a "Microservice" approach. Instead of one giant booth, they built a modern, high-tech stadium with hundreds of specialized stations working together. Here is how they did it, explained simply:
1. The Team of Specialists (Microservices)
Instead of one giant computer doing everything, the system is split into five small, independent teams (services):
- The Membership Team: Handles your ID and who you are.
- The Ticket Team: Knows which trains are running and which seats are open.
- The Order Team: Manages your receipt and booking details.
- The Payment Team: Handles the money (like a secure cashier).
- The Gateway Team: Acts as the security guard at the front door, checking IDs and keeping out troublemakers.
If the "Order Team" gets tired, the "Ticket Team" keeps working. This means if one part breaks, the whole system doesn't crash.
2. The Security Guard (Traffic Control)
When a huge crowd rushes the door, the system needs a bouncer. They used a tool called Sentinel. Think of it as a smart security guard who counts how many people are trying to enter per second.
- If too many people try to buy tickets at once, the guard politely tells some to wait or redirects them, preventing the system from getting crushed.
- This stops the "cascading failure" where one slow part drags down the whole building.
3. The Speedy Librarian (Caching & Bloom Filters)
The system uses a super-fast memory bank called Redis (the Librarian) to answer questions like "Is there a seat on Train A?" without asking the main database (the heavy archive) every time. This makes the system incredibly fast.
However, sometimes people ask about seats that don't exist (like "Is there a seat on a train that doesn't run?"). If the Librarian doesn't know, they usually have to run to the heavy archive to check, which slows everything down.
- The Fix: They used a Bloom Filter. Imagine a magic checklist that can instantly tell you, "No, that seat definitely doesn't exist," without even checking the archive. This stops the system from wasting time on fake requests.
4. The Perfect Ledger (Data Consistency)
In a high-speed environment, you don't want to sell the last ticket to two people.
- The Problem: If the database updates slowly, the "fast memory" might still show a seat is available even after it's sold.
- The Fix: They used a tool called Canal. Think of Canal as a super-fast spy that watches the main database's diary (logs). The moment a ticket is sold in the diary, the spy instantly tells the "fast memory" to update. This ensures everyone sees the same truth instantly.
5. The Token Bucket (Preventing Overselling)
To stop two people from grabbing the last ticket at the exact same millisecond, they created a Token Bucket in the fast memory.
- Imagine a bucket with exactly 10 tickets (tokens) inside.
- When someone wants to buy a ticket, they must grab a token from the bucket first.
- Because the bucket is managed by a single, strict rule (atomic operation), only one person can grab a token at a time. If the bucket is empty, the request is rejected immediately. This guarantees that no more tickets are sold than actually exist.
6. The Unique ID Generator
Every ticket needs a unique number. Old systems used random numbers (like UUIDs), which are like scattering puzzle pieces all over the floor. It's hard to find them later.
- The Fix: They used the Snowflake Algorithm. This generates numbers that are like a perfectly ordered line of puzzle pieces. They are unique, but they also go up in order (1, 2, 3...), making it much faster for the computer to find and store them.
The Results
After building this system, they tested it by simulating a massive rush.
- Speed: The system could handle 817 train inquiries per second with an average wait time of just 31 milliseconds (faster than a blink).
- Buying Tickets: It could process 265 ticket purchases per second.
- Safety: There was zero overselling. No one ever bought a ticket that didn't exist.
In short, the authors built a ticketing system that acts like a well-organized, high-tech stadium with specialized teams, smart security guards, and a magic checklist, ensuring that even during the busiest holidays, the system stays fast, stable, and fair for everyone.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.