A simple room inventory example from a senior developer’s perspective
Introduction
As systems scale, managing shared state becomes harder than writing business logic itself. Whether it’s inventory, bookings, or financial transactions, concurrency problems can quickly lead to data corruption, race conditions, and unhappy users.
In this post, I’ll walk through how Apache Geode can be used with .NET Core to handle:
- Distributed locking
- Concurrent access
- Reliable persistence to SQL Server
We’ll keep the example intentionally simple: a room inventory system — but the same pattern applies to much larger enterprise systems.
The Problem: Concurrency in Distributed Systems
Imagine a hotel booking platform:
- Multiple users try to reserve the same room
- Requests come from multiple application instances
- Data must stay consistent across the cluster
If two services decrement the room count at the same time, you risk overbooking.
Traditional database locking alone often doesn’t scale well under high concurrency. This is where a distributed data grid like Apache Geode fits naturally.
Why Apache Geode?
Apache Geode is an in-memory, distributed data platform that provides:
- Low-latency data access
- Distributed locking
- Strong consistency guarantees
- Write-through / write-behind persistence
Think of Geode as a shared, authoritative state layer that sits between your application and the database.
Architecture Overview
.NET Core API
|
Apache Geode (Distributed Cache + Locking)
|
SQL Server (Persistent Storage)
The application reads and updates room inventory in Geode. SQL Server acts as the system of record.
Room Inventory Model
Each room type has a total available count.
RoomInventory
- RoomType
- AvailableRooms
The critical requirement is simple:
Only one reservation should decrement inventory at a time — across all application instances.
Distributed Locking with Apache Geode
Apache Geode supports distributed locking using regions.
Conceptually, the flow looks like this:
- Acquire a distributed lock on the room type
- Read current availability
- Update availability
- Release the lock
.NET Core – Pseudocode Example
var region = geodeClient.GetRegion("RoomInventory");
using (region.AcquireLock(roomType))
{
var inventory = region.Get(roomType);
if (inventory.AvailableRooms <= 0)
throw new Exception("No rooms available");
inventory.AvailableRooms--;
region.Put(roomType, inventory);
}
This lock is respected cluster-wide, not just within a single application instance.
Handling Concurrency Safely
With this approach:
- Multiple API instances can run safely
- No race conditions occur during updates
- Business rules remain centralized
This is far safer than relying on application-level synchronization or optimistic retries alone.
Persisting Data to SQL Server
Geode doesn’t replace your database — it complements it.
Using write-through or write-behind persistence:
- Updates are written to Geode first
- Changes are persisted to SQL Server asynchronously or synchronously
Why this matters
- Low latency reads from memory
- Durable storage in SQL Server
- Resilience during traffic spikes
Even if the application restarts, Geode can reload state from SQL Server.
Why Developers Should Care
From a developer’s perspective, this pattern offers:
- Clear concurrency guarantees
- Scalable architecture without complex locking logic
- Clean separation between business logic and persistence
Instead of fighting race conditions, developers can focus on delivering features.
Where This Pattern Works Well
- Room or seat inventory systems
- Financial transaction processing
- Order management platforms
- High-traffic booking or reservation systems
Final Thoughts
Distributed systems fail in subtle ways — especially under concurrency.
Using Apache Geode with .NET Core provides a powerful, enterprise-grade solution for managing shared state safely, while SQL Server ensures long-term persistence.
This isn’t about adding complexity — it’s about choosing the right tool to simplify correctness at scale.
