Building a Scalable Slot Booking System with Redis Distributed Locks

#webdev #javascript #beginners #redis

In today's fast-paced digital world, seamless and scalable booking systems are essential, especially when multiple users are trying to book the same time slot simultaneously. This blog outlines a low-level design of a Slot Booking System using Redis for distributed locking, which ensures that users can book slots without encountering race conditions. By leveraging Redis, we can manage concurrency and scalability, ensuring that our booking system performs efficiently under high demand.

Key Components of the System

Before diving into the technical aspects, let's break down the core components:

User: Represents individuals using the system to book slots.
Slot: Represents time-bound units (e.g., meeting rooms, events) that users can book.
Redis Distributed Lock: The key feature that ensures two users can't book the same slot at the same time.
MongoDB: Stores the user and slot information.
Redis: Acts as the lock manager to handle race conditions.

The Challenges of Booking Systems

Booking systems can easily fall prey to issues like double booking or race conditions when multiple users attempt to book the same slot concurrently. Without proper concurrency control, two users may inadvertently book the same slot, leading to frustration and conflicts.

This is where Redis distributed locks come into play. Using a lock ensures that only one user can book a slot at any given time.

1. Models: Defining Users and Slots

To start with, we need to design our data models for users and slots. These models will be stored in MongoDB, and their structure is simple but effective.

a. User Model

Each user has basic attributes like a name, email, and a hashed password for authentication:

const mongoose = require('mongoose');

const UserSchema = new mongoose.Schema({
    name: { type: String, required: true },
    email: { type: String, required: true, unique: true },
    password: { type: String, required: true },
    createdAt: { type: Date, default: Date.now }
});

module.exports = mongoose.model('User', UserSchema);

b. Slot Model

Each slot has a start and end time, and it tracks whether it has been booked and by whom:

const mongoose = require('mongoose');

const SlotSchema = new mongoose.Schema({
    startTime: { type: Date, required: true },
    endTime: { type: Date, required: true },
    isBooked: { type: Boolean, default: false },
    bookedBy: { type: mongoose.Schema.Types.ObjectId, ref: 'User', default: null }
});

module.exports = mongoose.model('Slot', SlotSchema);

2. API Endpoints: How Users Interact with the System

APIs are the bridge between users and the system. Here are the key endpoints needed:

a. User Registration

Allows a new user to register:

Endpoint: POST /api/users/register
Request: User details (name, email, password)
Response: User registration confirmation

b. User Login

Authenticates the user and provides a JWT token:

Endpoint: POST /api/users/login
Request: User credentials (email, password)
Response: JWT token for authentication

c. Create Slot

Allows admins or authorized users to create slots:

Endpoint: POST /api/slots/create
Request: Slot start and end times
Response: Confirmation of slot creation

d. Book Slot

Allows users to book available slots:

Endpoint: POST /api/slots/book/:id
Request: JWT token in the header, slot ID in the URL
Response: Slot booking confirmation or error (e.g., if the slot is already booked)

3. How Redis Distributed Locks Work

Concurrency is the biggest challenge for booking systems. When multiple users attempt to book the same slot at the same time, Redis comes to the rescue with its distributed locking capabilities.

The Booking Process with Redis Locks

Lock Acquisition:
- When a user tries to book a slot, the system attempts to acquire a lock in Redis using the SET lock_key NX EX 10 command.
- The NX (set if not exists) ensures the lock is only created if it doesn't already exist, while EX 10 ensures that the lock expires after 10 seconds (preventing deadlocks).
- If the lock is already acquired, the system returns a 423 Locked status, informing the user that the slot is being booked by someone else.
Slot Availability Check:
- If the lock is successfully acquired, MongoDB is queried to check if the slot is still available (i.e., not booked).
- If the slot is available, the system updates the slot’s status to booked and sets the bookedBy field to the current user’s ID.
Lock Release:
- Once the booking process is complete, or if an error occurs, the system releases the lock by deleting the Redis key using the DEL lock_key command.

Sample Code for Booking a Slot with Redis Locks:

const redis = require('../config/redisClient');
const Slot = require('../models/Slot');

exports.bookSlot = async (req, res) => {
    const slotId = req.params.id;
    const userId = req.user.id;
    const lockKey = `lock:slot:${slotId}`;

    try {
        const lock = await redis.set(lockKey, userId, 'NX', 'EX', 10); // Try to acquire lock

        if (!lock) {
            return res.status(423).json({ msg: 'Slot is being booked by someone else. Please try again later.' });
        }

        const slot = await Slot.findById(slotId);
        if (!slot || slot.isBooked) {
            await redis.del(lockKey); // Release lock
            return res.status(400).json({ msg: 'Slot already booked or does not exist.' });
        }

        slot.isBooked = true;
        slot.bookedBy = userId;
        await slot.save();

        await redis.del(lockKey); // Release lock

        return res.json({ msg: 'Slot successfully booked', slot });
    } catch (error) {
        await redis.del(lockKey); // Release lock in case of error
        return res.status(500).json({ msg: 'Server error' });
    }
};

4. Error Handling in the Booking System

Handling errors gracefully is a vital part of any robust system. Here are some of the errors the system handles:

400 Bad Request: When the input data is invalid.
404 Not Found: When the requested slot or user is not found.
423 Locked: When a slot is currently being booked by another user.
500 Internal Server Error: For any unexpected errors, such as database or Redis failures.

5. Securing the System

Security is critical, especially when users are booking resources. Here’s how the system ensures security:

JWT Authentication: Every request for slot booking requires a valid JWT token, ensuring only authenticated users can access the system.
Data Validation: Input data is validated at every step to prevent invalid or malicious data from being processed.
Lock Expiry: Redis locks have a built-in expiration time (10 seconds) to prevent deadlocks if a booking process fails midway.

6. Scalability Considerations

The system is built with scalability in mind. As demand increases, the following strategies can ensure smooth operations:

Redis for Concurrency: Redis locks ensure that even with multiple instances of the application running, race conditions are avoided.
Redis Clustering: If the system grows significantly, Redis Clustering can be used to distribute the load across multiple Redis nodes, improving performance.

Conclusion

Building a scalable and reliable Slot Booking System requires careful consideration of concurrency, data integrity, and security. By using Redis distributed locks, we can ensure that no two users book the same slot simultaneously, eliminating race conditions. Additionally, by leveraging MongoDB for data persistence and JWT for authentication, this system is secure, scalable, and efficient.

Whether you're designing a booking system for meeting rooms, events, or any other time-bound resource, this architecture provides a strong foundation for managing bookings reliably under heavy load.