DEV Community: Roomnexa

How to Prevent Duplicate Bookings in a SaaS Application with Idempotency

Roomnexa — Mon, 05 Oct 2026 12:02:12 +0000

Imagine a guest is booking a hotel room.
They click "Confirm Booking".
The request takes a few seconds because of network latency. The user thinks nothing happened and clicks the button again.
Now the backend receives two requests.
If the API processes both requests independently, the application might create:

Two reservations
Two payment attempts
Two booking numbers
Duplicate emails
Incorrect room availability This is a common problem in transactional SaaS applications. The solution is idempotency. In this article, we'll look at what idempotency means, why it matters for booking APIs, and how it can be implemented in a typical Node.js backend.

What Is Idempotency?
An operation is idempotent when performing it multiple times produces the same final result as performing it once.
For example:
Request 1 → Create booking → BK-1001
Request 2 → Same request → BK-1001
Request 3 → Same request → BK-1001
Instead of creating three bookings, the server recognizes that these requests represent the same operation.
This is especially important for APIs involving:

Payments
Orders
Reservations
Ticket purchases
Account creation
Subscription activation
Inventory operations

Why Duplicate Requests Happen
Duplicate requests aren't always caused by users double-clicking.
They can happen because of:

Double-clicking A user clicks the submit button multiple times.
Network retry The client sends a request but doesn't receive the response because of a temporary network problem. The client retries.
Mobile connectivity A mobile application may lose connectivity immediately after sending a request. The user tries again.
Browser refresh The frontend may repeat a request after a page reload or navigation.
Automatic retry mechanisms Some HTTP clients, gateways or infrastructure components may retry failed requests. So simply disabling the button on the frontend is not enough. The backend should also protect the operation.

The Basic Idea
The client generates a unique idempotency key for an operation.
For example:
Idempotency-Key:
8f8d9c7e-5d4b-4b92-a2c1-123456789abc
The client sends it with the request:
POST /api/bookings
Idempotency-Key: 8f8d9c7e-5d4b-4b92-a2c1-123456789abc
The backend checks whether this key has already been processed.
If it hasn't:
Create booking
Store result
Return response
If it has:
Return previously stored result

A Simple Database Design
One approach is to create an idempotency table.
For example:
CREATE TABLE idempotency_keys (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
idempotency_key VARCHAR(255) NOT NULL UNIQUE,
request_hash VARCHAR(64),
response_status INT,
response_body JSON,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
The important part is:
UNIQUE(idempotency_key)
This prevents multiple records from being created for the same key.

Node.js Example
Let's imagine we're using Express.
A simplified booking endpoint could look like this:
app.post("/api/bookings", async (req, res) => {
const idempotencyKey = req.headers["idempotency-key"];

if (!idempotencyKey) {
    return res.status(400).json({
        message: "Idempotency-Key is required"
    });
}

const existingRequest = await db.idempotencyKeys.findUnique({
    where: {
        idempotencyKey
    }
});

if (existingRequest) {
    return res
        .status(existingRequest.responseStatus)
        .json(existingRequest.responseBody);
}

// Continue with booking creation...

});
After successfully creating the booking, we store the response:
const booking = await createBooking(req.body);

const responseBody = {
success: true,
bookingId: booking.id,
bookingNumber: booking.bookingNumber
};

await db.idempotencyKeys.create({
data: {
idempotencyKey,
responseStatus: 201,
responseBody
}
});

return res.status(201).json(responseBody);
This is only a simplified example. In production, the database transaction needs to be designed carefully.

The Important Part: Database Transactions
There is a subtle problem with the simple implementation.
Imagine this sequence:
Request A
↓
Check idempotency key
↓
Key doesn't exist
↓
Create booking
↓
Server crashes
↓
Response never returned
The user retries.
Now the second request may not know what happened.
This is why idempotency and transactional database operations often need to work together.
A safer flow is:
BEGIN TRANSACTION

Check idempotency key

If exists:
    Return stored response

Create booking

Store idempotency result

COMMIT
The exact implementation depends on the database and architecture, but the important principle is to make the state changes atomic wherever possible.

Don't Trust the Idempotency Key Alone
There is another important consideration.
Suppose a client sends:
Idempotency-Key: ABC123
with this request:
{
"roomId": 101,
"checkIn": "2026-10-10",
"checkOut": "2026-10-12"
}
Later, the same key is accidentally reused with:
{
"roomId": 205,
"checkIn": "2026-10-15",
"checkOut": "2026-10-18"
}
Should the server accept it?
No.
The idempotency key should represent one specific operation.
That's why storing a hash of the original request can be useful.
For example:
Idempotency Key
+
Request Hash
↓
Stored Operation
If the same key arrives with a different request payload, the API can reject it.

Request Hashing
A simplified example using Node.js:
import crypto from "crypto";

function createRequestHash(data) {
return crypto
.createHash("sha256")
.update(JSON.stringify(data))
.digest("hex");
}
Then:
const requestHash = createRequestHash(req.body);
The backend can compare the new hash with the hash stored for the idempotency key.
If they don't match:
409 Conflict
or another appropriate client error can be returned.

Frontend Protection Still Matters
Backend idempotency should not replace frontend UX.
You should still prevent accidental multiple submissions.
For example:
const [loading, setLoading] = useState(false);

const handleBooking = async () => {
if (loading) return;

setLoading(true);

try {
    await createBooking();
} finally {
    setLoading(false);
}

};
The frontend improves the user experience.
The backend provides the actual data integrity protection.
You need both.

Where Idempotency Becomes Really Important
A booking API is only one example.
Consider a payment flow:
Create Booking
↓
Initialize Payment
↓
Payment Gateway
↓
Payment Success
↓
Activate Booking
↓
Send Confirmation
If the payment callback is delivered twice, the backend should not:
Update payment twice
Generate two invoices
Activate booking twice
Send duplicate confirmations
Payment callbacks should therefore also be designed with idempotency in mind.

Idempotency vs Database Constraints
These solve related but different problems.
A database constraint might prevent:
duplicate booking number
But it doesn't necessarily prevent:
duplicate payment attempt
duplicate email
duplicate external API request
duplicate business operation
Idempotency is about making the operation itself safe to repeat.
Database constraints are one of the mechanisms that help enforce data integrity.
Good systems usually need both.

A Practical Booking Architecture
A production booking system can follow a flow similar to:
Client
|
| POST /bookings
| Idempotency-Key
↓
API Server
|
↓
Validate Request
|
↓
Check Idempotency
|
├── Already Processed
| ↓
| Return Existing Result
|
└── New Request
↓
Database Transaction
↓
Check Availability
↓
Create Reservation
↓
Store Idempotency Result
↓
Commit
↓
Return Response
This approach becomes particularly useful when a system handles reservations, payments and inventory simultaneously.

What About Redis?
For high-traffic systems, Redis can also be used for temporary idempotency state.
For example:
SET idempotency:ABC123 processing NX EX 300
The NX option means the key is only created if it doesn't already exist.
This can help coordinate concurrent requests.
However, Redis should not automatically replace your database as the source of truth.
The right architecture depends on:

Transaction requirements
Failure scenarios
Request volume
Data retention
Consistency requirements
Distributed system architecture

Testing Idempotency
Don't just test the happy path.
Test:
Same request twice
Request A → Success
Request A → Same result
Same request simultaneously
Request A ─┐
├→ Backend
Request A ─┘
Only one booking should be created.
Same key with different payload
Key: ABC123
Payload: Room 101

Key: ABC123
Payload: Room 205
The second request should be rejected.
Server failure
Simulate a failure after the database operation but before the response reaches the client.
Then retry the request.
The system should not create a second booking.

The Bigger Lesson
Idempotency isn't just a feature for payment APIs.
It is a general backend design principle.
Whenever an API performs an operation that should happen only once, ask:
What happens if this request arrives twice?

If the answer is:
"It will create another record."

then the endpoint probably needs better protection.
For SaaS applications, especially systems handling bookings, payments, orders or inventory, designing APIs for safe retries can prevent some very difficult production bugs.

Final Thoughts
Users will double-click.
Networks will fail.
Requests will time out.
Clients will retry.
Servers will restart.
These aren't unusual edge cases. They are normal conditions in distributed applications.
A robust backend should be designed with these realities in mind.
Idempotency gives APIs a way to safely handle repeated requests without accidentally repeating the business operation.
For applications such as hotel management platforms, where a single duplicate request can affect reservations, room availability, payments and guest communication, this small architectural decision can make a significant difference.
Build APIs assuming requests can be repeated — because eventually, they will be.

How a Cloud-Based Hotel PMS Can Simplify Hotel Operations

Roomnexa — Fri, 02 Oct 2026 11:14:50 +0000

Modern hotel operations involve much more than managing reservations.

A hotel team may need to handle room availability, guest check-in and check-out, housekeeping, billing, payments, restaurant orders, channel management, booking requests, and daily reports — often at the same time.

When these activities are managed through disconnected tools or manual processes, it can become difficult to keep information synchronized.

This is where a cloud-based Hotel Property Management System (PMS) can make a significant difference.

A hotel PMS brings important operational workflows into a centralized platform, allowing hotel teams to manage property information and daily activities from one place.

What Is a Hotel PMS?

A Hotel Property Management System is software designed to help hospitality businesses manage their day-to-day operations.

Depending on the platform, a PMS can include functionality such as:

Reservation management
Room and availability management
Front desk operations
Guest management
Check-in and check-out
Housekeeping
Billing and invoicing
Payment management
Restaurant POS
Channel management
Booking engine
Reports and analytics

Instead of maintaining separate systems for every operation, a PMS can connect these workflows and provide a centralized view of the property.

1. Managing Reservations and Room Availability

Reservations are one of the most important parts of hotel operations.

A reservation can affect room availability, pricing, housekeeping schedules, guest information, and the front desk workflow.

A cloud-based PMS can maintain real-time room availability and reservation information.

For example, when a room is booked, the availability status can be updated in the system. When a guest checks out, the room can move into the appropriate housekeeping workflow.

This creates a connected process instead of requiring staff to update multiple systems manually.

2. Simplifying Front Desk Operations

The front desk is responsible for many activities throughout the guest journey.

Staff may need to:

Check upcoming reservations
Allocate rooms
Check guests in
Update guest information
Process payments
Extend stays
Change room assignments
Complete check-outs

A centralized PMS can bring these activities together in a single interface.

This can help front desk teams spend less time searching for information across different tools and more time assisting guests.

3. Connecting Housekeeping With Room Status

Housekeeping and front desk operations are closely connected.

For example, after a guest checks out, the room may need cleaning before it can be assigned to another guest.

A PMS can maintain room statuses such as:

Vacant
Occupied
Dirty
Clean
Inspected
Out of service

When room status changes are reflected in the system, front desk staff can have better visibility into which rooms are ready for allocation.

This is especially useful for properties managing a large number of rooms.

4. Centralized Billing and Payments

Billing is another area where manual processes can create unnecessary work.

A hotel may need to manage room charges, additional services, restaurant orders, taxes, discounts, payments, and invoices.

A PMS can bring these transactions together and help generate a consolidated bill for the guest.

For properties operating in India, GST-related billing is also an important requirement.

A hotel management platform can provide configurable tax and invoice workflows so that businesses can manage their billing processes according to their applicable tax requirements.

The exact tax treatment should always be configured according to the property's accounting and regulatory requirements.

5. Restaurant and POS Integration

Hotels often operate restaurants, cafés, room service, or other food and beverage operations.

If restaurant orders and hotel billing are completely separated, staff may have to manually transfer charges between systems.

An integrated restaurant POS can connect food and beverage transactions with hotel operations.

For example, a restaurant order can be associated with a guest or room and later included in the guest's overall billing workflow, depending on the hotel's configuration.

This creates a more connected guest experience and reduces repetitive data entry.

6. Channel Management

Hotels often receive bookings from multiple sources.

These may include:

Direct website bookings
Online travel agencies
Booking platforms
Walk-in bookings
Phone reservations
Corporate bookings

Managing availability separately on each channel can create synchronization challenges.

A channel management system can help synchronize room availability and reservation information across connected channels.

The goal is to reduce the need for repetitive manual updates and provide a more consistent view of inventory.

7. Direct Booking Through a Booking Engine

Online travel agencies can provide valuable booking demand, but hotels may also want to accept reservations directly through their own websites.

A booking engine can allow guests to view available rooms, select dates, provide guest details, and complete the booking process through the property's website.

When connected with the PMS, direct bookings can become part of the same reservation workflow used by the hotel team.

This creates a more centralized approach to managing bookings from different sources.

8. Real-Time Access With Cloud Technology

One of the major differences between traditional on-premise systems and cloud-based software is accessibility.

With a cloud-based PMS, authorized users can access the system through supported devices and an internet connection.

This can be useful for hotel businesses where managers or owners need visibility beyond the front desk.

For example, a property manager may need to check:

Today's occupancy
Upcoming reservations
Room availability
Revenue information
Pending tasks
Housekeeping status

Cloud access can make this information available without requiring the user to be physically present at a particular computer.

9. Reports and Operational Insights

Hotel teams need more than operational screens. They also need useful information for making business decisions.

A PMS can provide reports related to areas such as:

Reservations
Occupancy
Room revenue
Payments
Cancellations
Guest activity
Housekeeping
Restaurant operations

Having this information in one system can make it easier for management teams to review hotel performance and identify operational patterns.

The usefulness of reporting depends on the quality and accuracy of the underlying data.

10. Why Integration Matters

The biggest benefit of a modern PMS is not necessarily the number of features it contains.

The more important question is how those features work together.

Consider a simple guest journey:

Booking → Room Allocation → Check-in → Stay → Restaurant Order → Housekeeping → Payment → Check-out

If each step uses a separate system without proper integration, information may need to be entered multiple times.

With an integrated PMS, these workflows can be connected.

For example:

A reservation is created.
Room availability is updated.
The guest checks in.
The room status changes to occupied.
Restaurant charges can be associated with the guest or room.
Housekeeping receives the relevant room status.
Charges are included in the billing workflow.
The guest completes check-out.
The room moves into the appropriate housekeeping status.

This connected workflow is one of the main reasons hotels are adopting modern cloud-based PMS platforms.

What Should Hotels Consider When Choosing a PMS?

There is no single PMS that is perfect for every hotel.

Before choosing a system, hospitality businesses should evaluate their actual operational requirements.

Some important considerations include:

Ease of Use

Hotel employees work in a fast-paced environment. A complicated interface can increase training time and make everyday tasks slower.

Scalability

The system should be able to support the hotel's current requirements while also accommodating future growth.

Integrations

Hotels should check whether the PMS can integrate with the tools and services they already use, such as payment gateways, OTAs, POS systems, accounting tools, and booking channels.

Security

Guest information and business data are sensitive. Hotels should understand how the provider handles authentication, access control, data protection, backups, and infrastructure security.

Reporting

Management should be able to access useful operational and financial information without relying entirely on manual spreadsheets.

Support

Reliable technical and operational support can be important, particularly when the PMS is used for critical daily hotel workflows.

Building Better Hotel Software

Building a hotel PMS is not simply a matter of creating a booking form and a room list.

Hospitality software needs to represent real operational workflows.

Room availability, reservations, room status, housekeeping, billing, payments, taxes, POS transactions, cancellations, modifications, and check-in/check-out processes can all affect one another.

For developers building hospitality software, this means the underlying data model and business logic are just as important as the user interface.

A change to a reservation, for example, may need to update availability, room allocation, pricing, billing, and operational reports.

This is why hotel software requires careful workflow design and testing.

[Roomnexa](https://roomnexa.com/

) and the Cloud PMS Approach

Roomnexa is a cloud-based Hotel Property Management System designed to bring essential hotel operations into a centralized platform.

The platform focuses on areas such as reservations, room management, front desk operations, housekeeping, billing, payments, restaurant POS, channel management, booking management, and reporting.

The idea is straightforward: instead of managing important hotel workflows through disconnected tools, hospitality teams can use a centralized system to manage their everyday operations.

Roomnexa is designed for hotels, resorts, guest houses, and growing hospitality businesses that are looking for a modern cloud-based approach to property management.

Conclusion

Hotel operations are becoming increasingly connected.

Reservations affect room availability. Room status affects housekeeping. Restaurant transactions can affect guest billing. Channel management affects inventory. Reports depend on accurate operational data.

A cloud-based Hotel PMS can connect these workflows and provide hotel teams with a centralized operational platform.

For hospitality businesses, the goal should not simply be to find software with the largest number of features.

The more important goal is to find a system that fits the property's actual workflow, integrates with the required tools, protects operational data, and remains easy for staff to use.

As hotel technology continues to evolve, connected and cloud-based systems can play an important role in making everyday hospitality operations simpler, more organized, and easier to manage.