DEV Community: sachin rajput

Preventing Race Conditions in Inventory Management Using Database Transactions

sachin rajput — Fri, 23 Oct 2026 07:51:01 +0000

Introduction

Inventory management looks simple at first: check how many items are available, confirm an order, and reduce the stock.

But what happens when two customers try to purchase the last item at exactly the same time?

If both requests read the same stock value before either request updates it, the application may accept both orders even though only one item was available. This is a classic example of a race condition.

In this tutorial, we will explore why this happens and how database transactions and atomic updates can help prevent overselling.

1. Understanding the Problem

Imagine an inventory table contains the following record:

Product	Available stock
Keyboard	1

Two customers submit an order simultaneously.

Request A reads stock = 1.
Request B reads stock = 1.
Both requests conclude that stock is available.
Both orders are accepted.

The application has now sold more units than it had available.

The problem is not simply that the database is slow. The problem is that checking stock and reserving it are separate operations without sufficient concurrency control.

2. Why a Simple Check Is Not Enough

Consider this simplified JavaScript logic:

if (product.stock > 0) {
  await createOrder(product.id);
  await updateStock(product.id, product.stock - 1);
}

This code illustrates the danger of a read-check-write sequence. Another request can execute between the check and the update.

Adding a transaction around arbitrary code is not automatically enough either. The database operations must be designed to prevent conflicting requests from both reserving the same stock.

3. Use an Atomic Conditional Update

One practical approach is to perform the stock check and decrement in a single database statement.

For PostgreSQL, the operation can look like this:

UPDATE products
SET stock = stock - 1
WHERE id = $1
  AND stock > 0
RETURNING id, stock;

The database checks the condition and updates the matching row as one statement.

If a row is returned, one unit was successfully reserved.
If no row is returned, the product does not exist or no stock is available.

Under PostgreSQL's normal transactional behaviour, concurrent updates to the same row are coordinated so that a later update rechecks the relevant condition after waiting for a conflicting update.

This is stronger than reading stock into application memory and updating it later.

4. Why Transactions Still Matter

Reserving stock is often only one part of an order workflow. The application may also need to create an order record and its associated order items.

These changes should remain consistent. For example, the application should not decrement inventory successfully and then leave the system with no corresponding order because a later database operation failed.

A transaction can group the operations:

BEGIN;

UPDATE products
SET stock = stock - 1
WHERE id = $1
  AND stock > 0
RETURNING id;

-- The application must verify that one row was returned.
-- If not, roll back the transaction.
-- Otherwise, insert the order record.

COMMIT;

This is a conceptual illustration. The application must inspect the returned rows and issue ROLLBACK when stock is unavailable or a required operation fails. Production code should also handle exceptions and transaction cleanup.

5. Implementing the Same Idea with an ORM

An ORM such as Prisma can make database access more convenient, but the same concurrency principles still apply.

A robust implementation should use a conditional update supported by the database and ORM, or an appropriate parameterized SQL statement. It should then create the order within a transaction and roll back if any required step fails.

The exact implementation depends on the schema, database provider, and ORM version. Avoid assuming that a normal read followed by a write is concurrency-safe merely because it is wrapped in a transaction.

6. Additional Production Considerations

Preventing negative stock is important, but a real order system has other concerns:

Idempotency: Retrying the same payment or order request should not accidentally create duplicate orders.
Payment failures: Inventory reservations may need to expire or be released if payment does not complete.
Deadlocks: Transactions that lock multiple rows should acquire locks in a consistent order where possible.
Testing: Simulate concurrent requests to verify that available stock is never oversold.
Monitoring: Track failed reservations, transaction errors, and unusual order patterns.

These concerns demonstrate why inventory management is a system-design problem rather than just a counter update.

7. How to Test the Fix

Create a product with one unit in stock, then submit two order requests concurrently.

The expected outcome is:

Only one request successfully reserves the final unit.
The other request receives an out-of-stock response.
The stock value never becomes negative.
A failed order does not leave partial database changes behind.

Repeat the test with larger stock values and more concurrent requests. Automated integration tests against the actual database are preferable to relying only on mocked responses.

Conclusion

Race conditions occur when concurrent operations make decisions using state that can change before their updates are completed.

Atomic conditional updates help protect individual inventory changes, while transactions keep related database operations consistent. Idempotency, error handling, and concurrency tests add further protection for real-world order workflows.

The key lesson is simple: enforce critical business rules at the database-operation level rather than relying only on checks performed in application code.

About the author: I am a Computer Science engineering student interested in full-stack development, database systems, and reliable software engineering.

This article presents a general implementation pattern. Verify it against your own project and database schema before describing it as a feature implemented in your repository.

Real-Time Collaboration with Socket.IO: How to Sync Drawing Events Across Multiple Users

sachin rajput — Fri, 23 Oct 2026 07:49:17 +0000

Introduction

Imagine two developers working on the same whiteboard from different locations. When one person draws a shape, the other should see it almost immediately without refreshing the page.

This is a real-time collaboration problem. It requires more than drawing on a canvas: the application must capture user actions, communicate changes to a server, and deliver those changes to the correct connected clients.

In this tutorial, we will explore how Socket.IO can help build the communication layer of a collaborative whiteboard using a simple event-driven architecture.

1. Why Traditional HTTP Requests Are Not Enough

Traditional HTTP works well when a client requests data and receives a response. However, repeatedly polling a server to discover every new drawing action can introduce unnecessary requests and delays.

Real-time applications need a way to deliver updates whenever events occur. WebSockets provide a persistent, bidirectional communication channel. Socket.IO builds on this idea and provides features such as event-based communication, reconnection handling, and rooms.

Socket.IO is not identical to the WebSocket protocol, and it may use different transports depending on the connection and configuration.

2. The Architecture

A basic collaborative whiteboard has three main parts:

Client: Captures drawing input and renders the canvas.
Server: Receives events and decides which clients should receive them.
Socket.IO rooms: Group users who are collaborating on the same board.

The event flow looks like this:

A user draws a line in the browser.
The client emits a drawing event with the necessary data.
The server validates the event and identifies the relevant room.
The server broadcasts the event to other users in that room.
Those clients render the incoming drawing operation.

This separates local interaction from communication and makes the system easier to reason about.

3. Connecting a Client to the Server

Install Socket.IO in a Node.js project:

npm install socket.io socket.io-client

A browser client can establish a connection to the server like this:

import { io } from "socket.io-client";

const socket = io("http://localhost:3000");

socket.on("connect", () => {
  console.log("Connected:", socket.id);
});

In a deployed application, use the configured backend URL rather than hardcoding localhost. A production frontend and backend may also require appropriate CORS settings and secure transport.

4. Using Rooms to Isolate Collaboration

A collaborative application may have many independent boards. Users on one board should not receive drawing events from another board.

Socket.IO rooms provide a useful way to isolate these groups.

A simplified server-side example:

io.on("connection", (socket) => {
  socket.on("join-board", (boardId) => {
    // Validate boardId and authorize access first.
    socket.join(boardId);
  });
});

The example demonstrates the basic mechanism. In a real application, never treat an arbitrary board ID as proof of permission. Validate the input and check whether the user is authorized to join that board.

5. Broadcasting Drawing Events

When a user draws, the client can send a small drawing operation instead of repeatedly transmitting an entire canvas image.

For example, a drawing event might contain the starting point, ending point, stroke colour, and brush width.

socket.emit("draw", {
  boardId: "board-123",
  from: { x: 10, y: 20 },
  to: { x: 30, y: 40 },
  color: "#222222",
  width: 3
});

The server can broadcast validated events to the other participants:

socket.on("draw", (payload) => {
  // Validate payload and authorize board access here.
  socket.to(payload.boardId).emit("draw", payload);
});

This is illustrative code, not a complete production implementation. The server must verify that the socket has joined the specified board and that every coordinate and style value is valid before broadcasting it.

The originating client can draw locally for responsiveness, while remote clients render the broadcast event. This pattern is often called optimistic local rendering.

6. Handling Real-World Problems

A working demonstration is only the beginning. Reliable collaboration requires attention to several edge cases.

Reconnection

A disconnected user may miss drawing events. Reconnecting the socket alone does not restore those events. The application needs a defined recovery strategy, such as fetching a saved board snapshot and replaying operations that occurred afterward.

Ordering and duplicate events

Rapid drawing actions can generate many events. Attach operation IDs or sequence numbers where appropriate, and design the receiver to handle duplicates safely.

Performance

Sending an event for every raw mouse movement can produce excessive traffic. Throttling, batching, simplifying stroke points, and limiting payload sizes can improve performance while preserving drawing quality.

Security

Validate every event on the server. Apply board-level authorization, rate limits, payload size limits, and safe connection configuration. A room name alone is not an access-control mechanism.

Persistence

If a new participant should see earlier drawings, the system needs persistent operations or a saved board snapshot. Broadcasting live events does not automatically save them.

7. How to Test a Collaborative Whiteboard

A simple manual test is to open the same board in two browser tabs.

Connect both tabs to the same board.
Draw from the first tab and verify that the second receives the update.
Open a different board and confirm that unrelated events are not delivered.
Disconnect one client, reconnect it, and verify the recovery behaviour.
Test malformed events, unauthorized board IDs, and unusually large payloads.

Testing these scenarios helps uncover problems that are easy to miss when only one browser is connected.

Conclusion

Real-time collaboration is fundamentally an event distribution problem. Socket.IO rooms, structured events, and server-side validation provide a useful foundation for collaborative applications.

However, production readiness also requires recovery after disconnections, sensible event ordering, performance controls, access control, and persistence when previous work must be retained.

By treating these concerns as part of the architecture rather than afterthoughts, developers can build collaborative experiences that are more responsive, secure, and maintainable.

About the author: I am a Computer Science engineering student interested in full-stack development, real-time systems, and building practical software applications.

Code examples in this article are simplified educational illustrations. Adapt and test them against the actual implementation of your project before publishing.

Building a Reliable AI-Powered IT Support Assistant with Rule-Based Troubleshooting

sachin rajput — Fri, 23 Oct 2026 07:45:17 +0000

Introduction

Modern IT support teams often handle repetitive issues such as login failures, application errors, and connectivity problems. Manually diagnosing every issue takes time and can lead to inconsistent troubleshooting.

An AI-powered IT support assistant can help users understand common problems, follow troubleshooting steps, and identify when an issue needs human intervention.

In this article, we will explore how rule-based troubleshooting and Large Language Models (LLMs) can work together to build a more reliable support assistant.

1. Why Combine Rules with AI?

AI models can understand natural-language questions and generate helpful explanations. However, their responses can sometimes be inaccurate or inconsistent.

Rule-based systems provide predictable behavior for known scenarios, while AI can help interpret questions that do not match predefined patterns.

A hybrid approach can offer three benefits:

Consistency: Known issues can follow predefined troubleshooting steps.
Flexibility: AI can help interpret different ways of describing the same problem.
Reliability: Validation and fallback mechanisms can prevent the application from depending entirely on AI-generated output.

2. Understanding the Architecture

A typical support assistant can be divided into four components:

User interface: Collects the user's issue and displays troubleshooting guidance.
Backend API: Validates requests and coordinates the troubleshooting process.
Rule-based engine: Handles known issues using predefined conditions and responses.
AI integration: Helps interpret more complex questions when appropriate.

The backend should remain responsible for validating inputs and controlling which operations are allowed.

3. A Simple Rule-Based Troubleshooting Example

Before introducing an AI model, we can implement a basic troubleshooting function in Python.

def troubleshoot(issue):
    issue = issue.lower().strip()

    rules = {
        "wifi": [
            "Check whether Wi-Fi is enabled.",
            "Reconnect to the network.",
            "Restart the router if necessary."
        ],
        "login": [
            "Verify your username.",
            "Check whether Caps Lock is enabled.",
            "Use the approved password recovery process."
        ]
    }

    for keyword, steps in rules.items():
        if keyword in issue:
            return {"matched": True, "steps": steps}

    return {
        "matched": False,
        "steps": [
            "Collect more details about the issue.",
            "Escalate to IT support if the issue persists."
        ]
    }

This example illustrates the basic idea: known problems receive predictable troubleshooting steps, while unmatched problems follow a fallback path.

This is a simplified demonstration, not a claim about the exact implementation used in the project.

4. Making AI Responses More Reliable

When integrating an LLM, the application should not blindly trust its output.

Useful safeguards include:

Validate user input before processing it.
Restrict AI responses to an expected structure.
Handle API timeouts and service failures gracefully.
Avoid exposing credentials, passwords, or sensitive system information.
Provide a clear escalation path when the assistant cannot confidently help.

AI should assist the troubleshooting process rather than replace security checks or human judgment.

5. Testing the Application

A reliable assistant should be tested with different categories of input:

Known issues, such as Wi-Fi connectivity problems.
Alternative descriptions of the same issue.
Empty or malformed input.
Questions outside the assistant's supported scope.
AI service failures and unexpected responses.

Tests should verify not only whether the assistant returns an answer, but also whether the answer follows the expected behavior.

6. Lessons Learned

Combining deterministic rules with AI can make a support assistant more predictable than relying on unrestricted AI-generated answers alone.

The most important engineering lesson is that reliability comes from the complete system: input validation, controlled processing, sensible fallbacks, testing, and appropriate human oversight.

Conclusion

AI-powered support tools can reduce repetitive work, but they need careful engineering to be useful in real-world environments.

Starting with clear rules, adding AI where it provides value, and designing explicit fallback paths is a practical way to build a more reliable troubleshooting experience.

About the author: I am a Computer Science engineering student interested in full-stack development, AI applications, and building practical software solutions.

Note: The code in this article is a simplified educational example. Replace it with verified examples from your own project before presenting it as actual project implementation.