Why e-commerce tests transactional design in HLD - Design It to Understand It

Design: E-commerce Transactional Testing System

Focus on testing transactional integrity in order processing, payment, and inventory management. Exclude UI/UX testing and marketing features.

Functional Requirements

FR1: Ensure all purchase transactions are processed correctly without data loss or corruption

FR2: Verify inventory updates accurately reflect purchases and returns

FR3: Confirm payment processing is reliable and consistent

FR4: Guarantee order status updates are consistent across all system components

FR5: Detect and handle transaction failures gracefully to avoid partial updates

Non-Functional Requirements

NFR1: Support up to 10,000 concurrent transactions

NFR2: Maintain data consistency with ACID properties

NFR3: Ensure p99 transaction processing latency under 500ms

NFR4: Achieve 99.9% system availability

NFR5: Handle rollback and recovery in case of failures

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Order Management System

Inventory Service

Payment Gateway

Database with transaction support

Test Automation Framework

Design Patterns

ACID Transactions

Two-phase commit

Eventual consistency with compensating transactions

Idempotency in payment processing

Retry and rollback mechanisms

Reference Architecture

User --> API Gateway --> Order Service --> Payment Service
                              |               |
                              v               v
                       Inventory Service   Database
                              |
                              v
                        Notification Service

Components

API Gateway

Nginx or AWS API Gateway

Entry point for user requests, routes to appropriate services

Order Service

Java Spring Boot or Node.js

Handles order creation, validation, and transaction coordination

Payment Service

External Payment Gateway API

Processes payments and ensures idempotent transactions

Inventory Service

Microservice with PostgreSQL

Manages stock levels and updates inventory atomically

Database

PostgreSQL with ACID support

Stores orders, payments, and inventory data with transactional guarantees

Notification Service

RabbitMQ and Email/SMS APIs

Sends order confirmation and status updates asynchronously

Request Flow

1. User sends purchase request to API Gateway

2. API Gateway forwards request to Order Service

3. Order Service starts a database transaction

4. Order Service calls Inventory Service to reserve stock

5. Inventory Service updates stock atomically and confirms

6. Order Service calls Payment Service to process payment

7. Payment Service processes payment with idempotency checks

8. If payment succeeds, Order Service commits transaction

9. If any step fails, Order Service rolls back transaction

10. Notification Service sends confirmation or failure message

Database Schema

Entities: User, Order, Payment, Inventory Relationships: - User 1:N Order - Order 1:1 Payment - Inventory tracks product stock levels All updates to Order, Payment, and Inventory happen within ACID transactions to maintain consistency.

Scaling Discussion

Bottlenecks

Database write locks causing delays under high concurrency

Payment gateway rate limits and latency

Inventory service contention on popular products

Notification service backlog during peak times

Solutions

Use database sharding and connection pooling to reduce lock contention

Implement payment request queuing and retries with exponential backoff

Apply optimistic concurrency control and caching in Inventory Service

Use message queues with multiple consumers to scale Notification Service

Interview Tips

Time: Spend 10 minutes understanding transactional requirements and constraints, 20 minutes designing the architecture and data flow, 10 minutes discussing scaling and failure handling, 5 minutes summarizing key points.

Importance of ACID transactions in e-commerce to prevent data inconsistency

How to handle partial failures with rollback and compensating actions

Use of idempotency to avoid duplicate payments

Trade-offs between strong consistency and system availability

Scaling strategies for high concurrency and fault tolerance

Practice

1. Why is transactional design important in e-commerce systems?

easy

A. It ensures all steps in a purchase either complete fully or not at all.

B. It speeds up the website loading time significantly.

C. It allows users to browse products without logging in.

D. It reduces the number of product categories displayed.

Solution

1. Step 1: Understand transaction purpose in e-commerce

   Transactions ensure that multiple related actions, like payment and order creation, happen together.

2. Step 2: Identify the benefit of transactional design

   This prevents partial updates that could cause errors like double charges or lost orders.

3. Final Answer:

   It ensures all steps in a purchase either complete fully or not at all. -> Option A

4. Quick Check:

   Transaction safety = B [OK]

Hint: Transactions keep all purchase steps together [OK]

Common Mistakes:

• Confusing transaction with website speed
• Thinking transactions only affect browsing
• Assuming transactions reduce product categories

2. Which of the following is the correct sequence to test a transaction in e-commerce?

easy

A. Check payment success, then update order status, then confirm inventory.

B. Update order status, confirm inventory, then check payment success.

C. Confirm inventory, update order status, then check payment success.

D. Confirm inventory, check payment success, then update order status.

Solution

1. Step 1: Understand transaction steps order

   First, confirm inventory is available to fulfill the order.

2. Step 2: Follow with payment and order update

   Then check payment success, and finally update order status to complete.

3. Final Answer:

   Confirm inventory, check payment success, then update order status. -> Option D

4. Quick Check:

   Correct transaction sequence = A [OK]

Hint: Inventory check before payment, then update order [OK]

Common Mistakes:

• Updating order before payment confirmation
• Checking payment before inventory availability
• Skipping inventory confirmation step

3. Consider this simplified transaction test code snippet:

beginTransaction()
if (checkInventory()) {
  if (processPayment()) {
    updateOrderStatus('confirmed')
    commitTransaction()
  } else {
    rollbackTransaction()
  }
} else {
  rollbackTransaction()
}

What happens if processPayment() fails?

medium

A. The transaction is rolled back, no changes saved.

B. Inventory is reduced but payment is not processed.

C. The order status is updated to 'confirmed'.

D. The transaction commits partially.

Solution

1. Step 1: Analyze payment failure branch

   If processPayment() returns false, the code calls rollbackTransaction().

2. Step 2: Understand rollback effect

   Rollback cancels all changes made in the transaction, so no order update or inventory change is saved.

3. Final Answer:

   The transaction is rolled back, no changes saved. -> Option A

4. Quick Check:

   Payment failure triggers rollback = C [OK]

Hint: Failed payment triggers rollback, no partial commit [OK]

Common Mistakes:

• Assuming order status updates despite payment failure
• Thinking inventory changes persist after rollback
• Believing partial commits happen on failure

4. A test for e-commerce transaction fails because orders are duplicated after retry. What is the likely cause?

medium

A. Order status is updated before payment confirmation.

B. Inventory check is done after payment processing.

C. The transaction does not rollback on failure.

D. The payment gateway is too slow.

Solution

1. Step 1: Identify duplication cause

   If orders duplicate after retry, it means failed transactions were not properly rolled back.

2. Step 2: Understand rollback role

   Rollback prevents partial or repeated writes; missing rollback causes duplicates.

3. Final Answer:

   The transaction does not rollback on failure. -> Option C

4. Quick Check:

   Missing rollback causes duplicates = D [OK]

Hint: No rollback on failure causes duplicate orders [OK]

Common Mistakes:

• Blaming payment speed for duplicates
• Confusing order update timing with duplication
• Ignoring rollback importance

5. In an e-commerce system, why must transactional tests cover both payment and inventory updates together?

hard

A. To allow partial order processing for faster checkout.

B. To ensure that if payment succeeds but inventory update fails, the whole operation is reversed.

C. To separate payment and inventory logic for easier debugging.

D. To reduce database load by splitting transactions.

Solution

1. Step 1: Understand atomicity in transactions

   Atomicity means all parts succeed or all fail together to keep data consistent.

2. Step 2: Apply atomicity to payment and inventory

   If payment succeeds but inventory update fails, the transaction must rollback to avoid errors like charging without stock.

3. Final Answer:

   To ensure that if payment succeeds but inventory update fails, the whole operation is reversed. -> Option B

4. Quick Check:

   Atomic transaction covers payment and inventory = A [OK]

Hint: Test payment and inventory as one atomic operation [OK]

Common Mistakes:

• Allowing partial order processing
• Separating payment and inventory for speed
• Splitting transactions to reduce load