From Number Guessing Game to System Design Concepts
this session, we started by building a simple Number Guessing Game, but the discussion slowly moved into system design concepts like locking, database design, randomness, and security. The idea was to not just build a game, but to understand how similar concepts apply in real-world systems.
Before this, we already discussed a ticket booking system, where multiple users try to book the same seat at the same time.
Ticket Booking System Problem
Consider two users trying to book the same seat.
User A selects seat 1
User B selects seat 1 at the same time
Both users see the seat as available and both attempt to book it.
This creates a race condition and leads to duplicate booking.
This happens because there is no locking mechanism.
Why Locking is Needed
To prevent this issue, we introduce locking.
When User A selects a seat:
- The seat gets locked
- User B cannot access it
- User A proceeds to payment
- If payment completes, seat becomes booked
- If payment times out, lock is released
This ensures only one user can access the seat at a time and maintains data consistency.
Types of Locking
Two types of locking were discussed.
Optimistic Locking
Assumes conflicts are rare. Multiple users can read data, and conflict is checked only when updating.
Pessimistic Locking
Locks the resource immediately. Other users cannot access it. This is safer and commonly used in booking systems.
Database Tables for Ticket Booking
Two tables are required.
Movies table stores:
- movie name
- show time
- release date
Seats table stores:
- movie id
- seat number
- status
Seat status is "available" by default.
Before booking begins, movie and seat details are inserted into these tables.
Booking Flow with Concurrency
User selects seat
Seat gets temporarily locked
User proceeds to payment
Lock held for limited time (example: 7 minutes)
If payment success → seat booked
If timeout → lock released
Without locking, multiple users can book the same seat.
Isolation levels help but do not fully solve concurrency issues.
Row Level Locking Example
Seat 1 is available
User A selects seat 1
Seat 1 becomes locked
User B tries to select seat 1
User B is blocked
Only when lock is released, seat becomes available again.
This demonstrates row level locking.
Number Guessing Game Design
After discussing concurrency, we moved to building a Number Guessing Game.
Two players try to guess a secret number within a range.
The goal is to guess the number with minimum attempts.
Difficulty levels define:
- range of numbers
- number of attempts
- score
Example:
Easy → 1 to 20
Medium → 1 to 50
Hard → 1 to 100
Leaderboard stores attempts and scores.
Game Flow
Start with greeting message
Show difficulty selection menu
User selects difficulty
Generate random number
User guesses number
System gives hint (higher / lower)
Track attempts
Store score in leaderboard
Random Number Generation
Computers do not generate truly random numbers.
They generate pseudo-random numbers using algorithms.
Random numbers depend on a seed value.
If the seed is same, the sequence will also be same.
Usually, system time is used as seed.
Different systems may produce different sequences.
So randomness is algorithm-based, not truly random.
Handling User Input
User input must be validated properly.
Difficulty input may come as string
Convert string to integer
Validate range
Handle invalid input
Functions return:
- int
- string
- boolean
Proper type conversion avoids runtime errors.
Leaderboard Design
Leaderboard data stored in database.
It contains:
- username
- difficulty
- attempts
- score
Operations include:
- inserting score
- fetching leaderboard
- sorting by attempts
- filtering by difficulty
Efficient queries and indexing improve performance.
System Design Takeaways
Concurrency handling is important
Locking prevents race conditions
Row level locking improves safety
Timeout based locking avoids deadlocks
Leaderboard stored in database
Efficient queries reduce load
Indexing improves performance
These concepts apply to real systems like:
- ticket booking
- ride booking
- hotel booking
- food delivery
Security and Network
Communication happens over HTTPS.
Security includes:
- TLS encryption
- public/private key pairs
- encrypted data transfer
This prevents middleman attacks and ensures secure communication.
This is important for:
- payments
- authentication
- booking systems
Summary
In this session, we learned:
Concurrency issues in booking systems
Optimistic vs pessimistic locking
Database table design
Row level locking
Number guessing game design
Random number generation
Input validation and type casting
Leaderboard system design
Security basics using HTTPS
This session showed how even a simple Number Guessing Game can help understand real-world system design concepts.
Top comments (0)