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📝 Trade-off Q15 of 15

LLD - Design — Splitwise (Expense Sharing)

AStore transactions in separate files per day without indexing

BStore all transactions in one big list and scan it every time

CUse a database with an index on user ID and timestamp

DKeep transactions only in memory without persistence

Step-by-Step Solution

Solution:

Step 1: Consider scalability and retrieval speed
Scanning one big list or files without index is slow for millions of users.
Step 2: Use database indexing on user ID and timestamp
This allows fast queries to get transactions per user sorted by time efficiently.
Step 3: Avoid in-memory only storage for persistence and scale
Memory-only storage risks data loss and limits scale.
Final Answer:
Use a database with an index on user ID and timestamp -> Option C
Quick Check:
Indexing = fast retrieval at scale [OK]

Quick Trick: 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

Master "Design — Splitwise (Expense Sharing)" in LLD

9 interactive learning modes - each teaches the same concept differently

Learn Why Deep Arch Try Challenge Design Recall Scale

Want More Practice?

15+ quiz questions · All difficulty levels · Free

Free Signup - Practice All Questions

More LLD Quizzes

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?

Step 1: Consider scalability and retrieval speed

Step 2: Use database indexing on user ID and timestamp

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

Final Answer:

Quick Check:

Want More Practice?