Transaction history in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Design a scalable transaction history storage system

You need to design a system that stores and retrieves transaction histories for millions of users efficiently. Which architectural choice best supports fast writes and reads while scaling horizontally?

A Use a distributed NoSQL database with sharding based on user ID.

B Use a single relational database with vertical scaling and complex indexing.

C Store all transactions in flat files on a single server and read sequentially.

D Use an in-memory cache only without persistent storage.

💡 Hint

Think about how to handle large data volumes and many users simultaneously.

Distributed NoSQL databases with sharding allow horizontal scaling and fast access by partitioning data by user ID, which suits transaction history storage.

❓ scaling

intermediate

Estimate storage needs for transaction history

Your system records 10 million transactions daily. Each transaction record is 1 KB. Estimate the storage needed for 1 year of data, considering 20% overhead for indexing and metadata.

A Approximately 3.65 TB

B Approximately 5.0 TB

C Approximately 2.92 TB

D Approximately 4.38 TB

💡 Hint

Calculate total raw data size, then add 20% overhead.

10 million transactions/day * 1 KB = 10 GB/day. For 365 days = 3.65 TB raw. Adding 20% overhead: 3.65 TB * 1.2 = 4.38 TB.

❓ tradeoff

advanced

Choosing between consistency and availability for transaction history

Your transaction history system must be highly available but also provide accurate data. Which tradeoff approach is best?

A Prioritize availability with eventual consistency, allowing temporary stale reads.

B Prioritize strong consistency with synchronous replication, sacrificing availability during network partitions.

C Use no replication to avoid consistency issues, risking data loss.

D Use asynchronous replication with no conflict resolution.

💡 Hint

Consider the CAP theorem and the system's need for availability.

Eventual consistency allows the system to remain available during network issues, accepting temporary stale data, which suits high availability needs.

❓ component

advanced

Identify the key components for a transaction history system

Which set of components is essential for a robust transaction history system that supports querying, storage, and data integrity?

A In-memory cache only, no persistent storage, no validation

B Load balancer, distributed database, query API, data validation module

C Single server, flat file storage, manual backups, no API

D Client-side storage, no server, no validation

💡 Hint

Think about components that ensure scalability, accessibility, and correctness.

A load balancer distributes requests, a distributed database stores data reliably, a query API allows access, and data validation ensures integrity.

🧠 Conceptual

expert

Trace the request flow for retrieving a user's transaction history

Describe the correct sequence of steps when a client requests their transaction history from a distributed system.

A 2,1,3,4,5,6

B 1,3,2,4,5,6

C 1,2,3,4,5,6

D 1,2,4,3,5,6

💡 Hint

Authentication must happen before routing the request.

The client request first reaches the API gateway, which authenticates the user, then routes the request to the correct service, which queries the database and returns data back through the gateway to the client.

Practice

1. What is the main purpose of a transaction history in a system?

easy

A. To record all important actions with details for tracking

B. To speed up the system by caching data

C. To delete old data automatically

D. To encrypt user passwords

Solution

1. Step 1: Understand the role of transaction history

   Transaction history stores records of actions with details like timestamps and IDs.

2. Step 2: Identify the correct purpose

   This helps users and systems track past events clearly and reliably.

3. Final Answer:

   To record all important actions with details for tracking -> Option A

4. Quick Check:

   Transaction history purpose = record actions [OK]

Hint: Transaction history = record actions with details [OK]

Common Mistakes:

• Confusing transaction history with caching
• Thinking it deletes data automatically
• Mixing it with security features like encryption

2. Which of the following is the correct way to uniquely identify each transaction in a history system?

easy

A. Using a timestamp only

B. Using a unique transaction ID

C. Using the user's name

D. Using the transaction amount

Solution

1. Step 1: Identify unique identifiers in transaction history

   Unique transaction IDs ensure each record is distinct and traceable.

2. Step 2: Compare options

   Timestamps alone can repeat; user names and amounts are not unique identifiers.

3. Final Answer:

   Using a unique transaction ID -> Option B

4. Quick Check:

   Unique ID = unique transaction record [OK]

Hint: Unique transaction ID ensures distinct records [OK]

Common Mistakes:

• Assuming timestamp alone is unique
• Using user name as unique key
• Using transaction amount as identifier

3. Given this simplified transaction record list:

transactions = [
  {"id": "t1", "time": "2024-01-01T10:00:00Z"},
  {"id": "t2", "time": "2024-01-01T09:00:00Z"},
  {"id": "t3", "time": "2024-01-01T11:00:00Z"}
]

What is the correct order of transaction IDs if sorted by time ascending?

medium

A. ["t1", "t2", "t3"]

B. ["t2", "t3", "t1"]

C. ["t3", "t1", "t2"]

D. ["t2", "t1", "t3"]

Solution

1. Step 1: Analyze timestamps for each transaction

   t2 = 09:00, t1 = 10:00, t3 = 11:00 in UTC time.

2. Step 2: Sort transactions by ascending time

   Order is t2 (earliest), then t1, then t3 (latest).

3. Final Answer:

   ["t2", "t1", "t3"] -> Option D

4. Quick Check:

   Sorted by time ascending = [t2, t1, t3] [OK]

Hint: Sort by timestamp ascending for correct order [OK]

Common Mistakes:

• Sorting by ID instead of time
• Confusing ascending with descending order
• Ignoring timestamp format

4. You have this code snippet to add a transaction record:

def add_transaction(history, transaction):
    if transaction['id'] not in [t['id'] for t in history]:
        history.append(transaction)
    else:
        print("Duplicate transaction")

history = [{"id": "t1"}]
add_transaction(history, {"id": "t1"})

What is the output when running this code?

medium

A. Duplicate transaction

B. KeyError exception

C. No output, transaction added

D. TypeError exception

Solution

1. Step 1: Check if transaction ID exists in history

   The code checks if 't1' is already in the list of IDs in history.

2. Step 2: Since 't1' exists, print duplicate message

   The else branch runs and prints "Duplicate transaction".

3. Final Answer:

   Duplicate transaction -> Option A

4. Quick Check:

   Duplicate ID detected = print message [OK]

Hint: Check for existing ID before adding to avoid duplicates [OK]

Common Mistakes:

• Assuming transaction is added anyway
• Expecting an exception instead of print
• Confusing list comprehension syntax

5. You want to design a scalable transaction history system for millions of users. Which approach best ensures fast retrieval of a user's transactions sorted by time?

hard

A. Store transactions in separate files per day without indexing

B. Store all transactions in one big list and scan it every time

C. Use a database with an index on user ID and timestamp

D. Keep transactions only in memory without persistence

Solution

1. Step 1: Consider scalability and retrieval speed

   Scanning one big list or files without index is slow for millions of users.

2. Step 2: Use database indexing on user ID and timestamp

   This allows fast queries to get transactions per user sorted by time efficiently.

3. Step 3: Avoid in-memory only storage for persistence and scale

   Memory-only storage risks data loss and limits scale.

4. Final Answer:

   Use a database with an index on user ID and timestamp -> Option C

5. Quick Check:

   Indexing = fast retrieval at scale [OK]

Hint: Index on user ID and timestamp for fast queries [OK]

Common Mistakes:

• Scanning large lists for each query
• Ignoring indexing benefits
• Relying on memory-only storage