High Concurrency Transaction System Design: Flash Sales, Ticket Grabbing & Financial Trading Architecture

Introduction: Transaction Systems are the Ultimate Test of High Concurrency

Double 11 at midnight, 100 million people rushing for limited items.

Concert ticket sales, 300,000 people crowding in.

Stock market opens, processing hundreds of thousands of transactions per second.

These scenarios share one common trait: Money-related systems can't afford errors.

Regular systems can restart when they crash. Transaction system errors lead to overselling, duplicate charges, and financial losses. The pressure is much greater than typical high concurrency scenarios.

This article starts with the special challenges of transaction systems, diving deep into the design essentials of flash sales, ticket grabbing, and financial trading systems.

If you're not familiar with high concurrency basics, we recommend first reading What is High Concurrency? Complete Guide.

---

1. Special Challenges of Transaction Systems

What makes transaction systems different from typical high concurrency systems?

1.1 Data Consistency Requirements

Regular systems: Occasional inconsistency is acceptable, eventual consistency is fine.

Transaction systems: Money deducted must have an order, orders must deduct inventory. Any inconsistency is an incident.

Examples:

• Payment succeeds but order not created → Customer complaint
• Order created but inventory not deducted → Overselling
• Inventory deducted but order failed → False inventory

1.2 Concurrency Conflicts

100 people simultaneously grabbing the last item. Without proper control:

• 100 people all see "in stock"
• 100 people all successfully order
• Actually only 1 item
• 99 orders become problem orders

1.3 Timeliness Requirements

Users expect "second-level" response.

• Flash sales: Know result within 500ms
• Ticket grabbing: Queue must show progress
• Financial trading: Millisecond-level latency

If processing is too slow, users repeatedly click, making problems worse.

1.4 Security Requirements

Transaction systems are attackers' favorites:

• Scalping, bots
• Duplicate submission (exploiting promotions)
• API attacks (bypassing limits)
• Data tampering

Every layer needs protection.

---

2. Flash Sale System Design

Flash sales are the most extreme transaction scenario: short time, ultra-high concurrency, limited inventory.

2.1 Flash Sale Characteristics

Characteristic	Description
Instant traffic	Almost no traffic before, instant explosion after start
Read-heavy, write-light	Many browse, few can buy
Hotspot concentration	All requests hit same product
Short duration	Usually ends in seconds to minutes

2.2 Traffic Shaping Strategies

The core problem of flash sales is overly concentrated traffic. Solution is "peak shaving."

Frontend Peak Shaving

1. Page static + CDN

   • Product detail page as static
   • CDN cache reduces server requests
   • Only "Buy Now" button hits backend

2. Countdown

   • Millisecond-precise countdown
   • Button clickable only when time arrives
   • Prevents premature requests

3. CAPTCHA / Slider

   • Distinguishes humans from machines
   • Adds operation time, spreads request intervals
   • Reduces scalper success rate

Backend Peak Shaving

1. Message Queue
   • Requests enter queue first, not processed directly
   • Consumed in queue order slowly
   • Users see "queuing"

User request → Enter queue → Return "queuing"
          ↓
      Backend consumer processes
          ↓
      Notify user when complete

2. Token Bucket Rate Limiting
   • Set how many requests per second to process
   • Reject excess directly
   • Protects backend from overload

2.3 Inventory Deduction Solutions

Inventory deduction is the core challenge of flash sales.

Solution 1: Database Deduction (Not Recommended)

UPDATE products SET stock = stock - 1 WHERE id = 123 AND stock > 0;

Problem: Database can't handle high concurrency, easily becomes bottleneck.

Solution 2: Redis Pre-deduction (Recommended)

-- Redis Lua script (atomic operation)
local stock = redis.call('GET', KEYS[1])
if tonumber(stock) > 0 then
    redis.call('DECR', KEYS[1])
    return 1  -- Deduction success
else
    return 0  -- Insufficient stock
end

Flow:

1. Before flash sale, load inventory into Redis
2. Use Lua script for atomic deduction
3. Only create order after successful deduction
4. After order creation, async sync to database

Solution 3: Distributed Lock

# Protect with Redis distributed lock
lock = redis.setnx(f"lock:product:{product_id}", unique_id)
if lock:
    try:
        stock = redis.get(f"stock:{product_id}")
        if stock > 0:
            redis.decr(f"stock:{product_id}")
            create_order(product_id, user_id)
    finally:
        redis.delete(f"lock:product:{product_id}")

For more Redis cache design, see High Concurrency Database Design.

2.4 Anti-Overselling Mechanism

Multi-layer Validation

Frontend validation → Redis pre-deduction → Database validation → Final confirmation

Failure at any layer returns failure.

Optimistic Locking

Use version number control at database layer:

UPDATE products
SET stock = stock - 1, version = version + 1
WHERE id = 123 AND stock > 0 AND version = 5;

If version doesn't match (someone else changed it), update fails.

3. Ticket Grabbing System Design

Ticket grabbing is similar to flash sales but emphasizes fairness and experience more.

3.1 Queuing Mechanism

Users don't like the "flash sale failed" experience. Better approach is "queuing."

Redis Sorted Set for Fair Queuing

# User enters queue
timestamp = time.time()
redis.zadd("queue:event:123", {user_id: timestamp})

# Get queue position
rank = redis.zrank("queue:event:123", user_id)
return {"position": rank + 1}

# Backend processing: fetch in order
users = redis.zrange("queue:event:123", 0, 99)  # 100 people at a time
for user in users:
    process_order(user)
    redis.zrem("queue:event:123", user)

Users see "You are currently #1,234 in queue" instead of "Purchase failed."

3.2 Fairness Design

Ticket grabbing's biggest fear is unfairness: scalpers using scripts to grab all tickets.

Countermeasures:

1. Human-machine Verification

   • Image CAPTCHA
   • Slider verification
   • Behavior verification (operation trajectory)

2. Purchase Limits

   • Limit N tickets per person
   • Redis records purchased quantity

   purchased = redis.incr(f"purchased:{event_id}:{user_id}")
   if purchased > MAX_TICKETS:
       return "Purchase limit reached"
   

3. Risk Control System

   • Device fingerprinting
   • IP frequency limits
   • Account behavior analysis
   • Machine learning anomaly detection

3.3 Order Processing Flow

User queues → Turn comes → Lock seat → Await payment → Payment success → Issue ticket
                                  ↓
                            Payment timeout → Release seat

Key Design:

• Lock has time limit: 15 minutes for payment, auto-release on timeout
• Partial success handling: Wanted 4 tickets but got 2, let user choose
• Waitlist mechanism: Notify waitlist when someone gives up

3.4 Case Study

Major Ticketing Platforms

Common approaches:

• Staggered release times (reduce instant pressure)
• Queuing mechanism (better user experience)
• Purchase limits + real name (anti-scalping)
• Waitlist mechanism (redistribute released tickets)

Remaining challenges:

• Hot events still sell out instantly
• Scalpers bypass limits with multiple accounts
• Instant traffic infrastructure challenges

---

4. Financial Trading System Design

Financial trading has extreme requirements for latency and correctness.

4.1 Low Latency Design

Every millisecond is money in financial trading.

Technical Methods:

1. In-memory Computing

   • Data in memory, no disk access
   • Use Redis, Hazelcast, etc.

2. Zero Copy

   • Reduce memory data copying
   • Use mmap, sendfile

3. Kernel Bypass

   • Bypass OS kernel
   • Use DPDK, RDMA

4. Programming Language Choice

   • C++, Rust, Go primarily
   • Avoid GC-caused latency

For detailed language comparison, see Python vs Golang High Concurrency.

4.2 Data Consistency

Financial trading must guarantee data correctness. In distributed environments, this is the biggest challenge.

2PC (Two-Phase Commit)

Classic distributed transaction protocol:

Coordinator → Prepare phase → All participants reply OK
      → Commit phase → All participants commit

Problems: Blocking, single point of failure, poor performance

TCC (Try-Confirm-Cancel)

Business-level distributed transaction:

Try: Reserve resources (freeze balance)
Confirm: Execute (deduct)
Cancel: Rollback (unfreeze balance)

# Try phase
def try_transfer(from_account, to_account, amount):
    freeze_balance(from_account, amount)
    reserve_credit(to_account, amount)
    return try_id

# Confirm phase
def confirm_transfer(try_id):
    deduct_frozen_balance(from_account, amount)
    credit_reserved(to_account, amount)

# Cancel phase
def cancel_transfer(try_id):
    unfreeze_balance(from_account, amount)
    release_reserved(to_account, amount)

Saga Pattern

Long transaction split into multiple local transactions, each with compensation:

T1 → T2 → T3 → T4 (success)

T1 → T2 → T3 (failure) → C2 → C1 (compensating rollback)

Suitable for microservices architecture, no distributed locks needed.

4.3 Risk Control Integration

Financial trading requires real-time risk control:

Synchronous Risk Control (pre-trade)

• Account status check
• Limit check
• Blacklist check
• Fraud detection

Asynchronous Risk Control (post-trade)

• Anomaly pattern analysis
• Association analysis
• Manual review

4.4 Compliance Requirements

Financial systems have strict compliance requirements:

• Audit Trail: Every transaction must be logged
• Data Retention: Retain N years per regulations
• Privacy Protection: Encrypt sensitive data
• Regulatory Reporting: Regular report generation

---

5. Duplicate Submission Prevention

Duplicate submission is a common problem in transaction systems.

5.1 Problem Sources

User Behavior

• Network slow, user clicks multiple times
• Browser refresh
• Back button then resubmit

System Behavior

• Timeout retry
• Inter-service call retry
• Message duplicate consumption

5.2 Idempotency Design

Idempotent: Same operation executed multiple times produces same result as executing once.

Method 1: Unique Request ID

Frontend generates unique ID, backend checks if already processed.

@app.post("/orders")
async def create_order(request_id: str, product_id: int):
    # Check if already processed
    if redis.get(f"request:{request_id}"):
        return {"message": "Order already created", "duplicate": True}

    # Mark as processing
    redis.setex(f"request:{request_id}", 3600, "processing")

    # Create order
    order = create_order_in_db(product_id)

    # Mark as complete
    redis.setex(f"request:{request_id}", 3600, order.id)

    return {"order_id": order.id}

Method 2: Business Idempotency Key

Combine business fields into unique key.

# Same user, same product, same time window can only order once
idempotent_key = f"{user_id}:{product_id}:{time_window}"

Method 3: State Machine

Orders have state transitions, only certain states allow certain operations.

Pending Payment → Paid → Shipped → Completed
          ↓
        Cancelled

5.3 Implementation Example

Token Mechanism

# Get Token
@app.get("/order/token")
async def get_order_token():
    token = str(uuid.uuid4())
    redis.setex(f"order_token:{token}", 300, "valid")
    return {"token": token}

# Verify Token when creating order
@app.post("/orders")
async def create_order(token: str, product_id: int):
    # Atomic operation: check and delete token
    if not redis.delete(f"order_token:{token}"):
        raise HTTPException(400, "Token invalid or already used")

    # Create order...

---

Transaction system architecture needs professional planning? Money-related system errors are too costly. Book a consultation and let experienced consultants help design your transaction architecture.

---

6. Practical Case Studies

6.1 E-commerce Double 11 Flash Sale

Background:

• Product: Limited 1,000 units
• Expected traffic: 1 million users
• Peak QPS: 50,000

Architecture Design:

Users → CDN (static pages)
    → ALB (load balancer)
    → API Gateway (rate limit 10,000 QPS)
    → SQS (message queue)
    → Order Service (10 instances)
    → Redis Cluster (inventory)
    → Aurora (order data)

Key Metrics:

• CDN hit rate: 95%
• Max queue depth: 50,000
• Average processing latency: 200ms
• Overselling incidents: 0

6.2 Concert Ticket Grabbing

Background:

• Seats: 10,000
• Expected traffic: 500,000 users
• Sale time: 10:00

Architecture Design:

1. 9:50 open queuing page
2. 10:00 start letting people in order
3. 1,000 people per batch enter seat selection
4. Complete payment within 15 minutes
5. Timeout seats released to waitlist

Key Metrics:

• Queue wait: average 5 minutes
• Payment timeout rate: 8%
• Waitlist success rate: 15%
• Complaint rate: 60% lower than pure flash sale

6.3 Stock Trading System

Background:

• Daily volume: 10 million transactions
• Latency requirement: < 10ms
• Availability: 99.99%

Architecture Design:

• Matching engine: C++ implementation, in-memory computing
• Order book: LMAX Disruptor architecture
• Database: Async writes, cached reads
• Risk control: Sync + async dual layer

Key Metrics:

• P99 latency: 5ms
• Daily availability: 99.995%
• Matches per second: 100,000

---

FAQ

Q1: Must flash sales use Redis?

Not necessarily, but strongly recommended. Redis's performance (100k+ QPS) and Lua script atomicity are perfect for flash sale scenarios. Databases usually can't handle it.

Q2: How to prevent scalpers?

Combination strategy: CAPTCHA, purchase limits, real name, device fingerprint, IP limits, behavior analysis. No 100% effective solution, but can greatly increase cost.

Q3: TCC or Saga?

TCC suits strong consistency scenarios (finance) but complex to implement. Saga suits eventual consistency scenarios (e-commerce), easier to implement.

Q4: What if overselling happens?

First admit the mistake, contact customers to apologize. Provide compensation (coupons, priority purchase rights). Post-mortem review to fix the vulnerability.

Q5: Will queuing be slower?

For individual users maybe slower, but better experience. Users know progress, won't frantically refresh. For system, traffic is smoother.

---

Conclusion: Transaction Systems Have No Room for Error

Transaction systems are the ultimate test of high concurrency. Can't be wrong, can't be slow, can't fail to handle load.

Key Takeaways:

1. Four challenges of transaction systems: consistency, concurrency conflicts, timeliness, security
2. Flash sales use peak shaving (CDN + queue) + Redis pre-deduction
3. Ticket grabbing uses queuing mechanism + fairness design
4. Financial trading uses low latency design + TCC/Saga for consistency
5. Idempotency design prevents duplicate submission
6. Multi-layer validation prevents overselling

Extended Reading:

• What is High Concurrency? Complete Guide
• High Concurrency Architecture Design
• High Concurrency Database Design
• High Concurrency Testing Guide
• Python vs Golang High Concurrency
• Cloud High Concurrency Architecture

---

Need a Second Opinion on Architecture?

Transaction system architecture relates to real money. If you're:

• Designing flash sale or ticket systems
• Handling distributed transaction consistency issues
• Planning financial-grade transaction systems

Book an architecture consultation and let's design reliable transaction architecture together.

All consultation content is completely confidential, no sales pressure.

---

References

1. Martin Kleppmann, "Designing Data-Intensive Applications" (2017)
2. Chris Richardson, "Microservices Patterns" (2018)
3. Alibaba, "Alibaba Double 11 Technology Secrets" (2019)
4. LMAX Exchange, "The LMAX Architecture" (2011)
5. AWS, "Building a Serverless Flash Sale System" (2023)