Inventory system: what breaks under parallel operations
A classic inventory system follows a read-modify-write pattern: a request takes the current state of an item, changes it in memory, and saves it back. As long as requests come one at a time, this goes unnoticed.
During simultaneous trades or crafting, both requests read the same data version, and the second silently overwrites the first's result.
In joint crafting, this produces negative balances: two clients deduct the last instance of a resource, and the server confirms both operations. Trades produce a mirror effect—one item goes to two recipients when deduction and grant are not performed as atomic item transactions. Ownership checks pass for both because the state has not yet changed between check and write.
Item duplicates also come from repeated requests.
A player clicks purchase, the response does not arrive due to a connection drop, the client repeats the request, and the server processes it as new: without an operation ID, the grant goes through twice, and a second instance appears in the inventory.
Loss of purchases on connection drop is the flip side of the same mechanics: the payment is confirmed by the platform, but the inventory write rolled back or never arrived.
The client shows the old state from local cache, client-server desync accumulates and diverges on every login until the server state becomes unexpected for the player.
Then manual triage kicks in: the flow of support requests grows, edits are made directly in the live database without tracing who changed a record and when. We explain how this is closed.
What operation atomicity delivers: integrity, speed, failures
Atomicity means that a trade, craft, or item transfer is committed in full or not committed at all. There is no state where an item disappears from one player and does not appear for another, even if the connection drops at the moment of writing.
For a project, this is the difference between a single support request and a wave of complaints after a mass event.
Integrity during mass trades, crafting, and item transfers
Each operation undergoes server validation and is written to the change log as a single record: deduction and grant happen inside a shared transaction with locking of the affected slots.
Crafting that consumes several stacks and player-to-player trades follow the same rule, so "half" a recipe cannot be applied.
Request idempotency handles resubmission: if a player did not wait for a response and clicked again, a second deduction will not happen—the repeat is recognized by the operation key, and exactly one change remains in the inventory.
Response under peak load and elimination of a class of failures
Under peak load—season start, event, reward distribution—the bottleneck is not the logic itself but contention for the same slots. We spread locks across a minimal set of objects and keep frequent operations in memory, while heavy ones go into a queue with sequential processing. Response time for ordinary inventory actions does not grow with the number of players.
The class of failures changes qualitatively: instead of "item disappeared" or "item duplicated," only failures of the "operation rejected, state unchanged" type remain. Players see such cases as a clear message and can repeat the action, rather than as lost progress.
In acceptance testing, this is checked simply: discrepancies after mass trades, duplicate rate, and peak response time—three metrics that show the inventory system withstands the load of a live game.
How the inventory system is structured: storage and synchronization modes
Choosing between an event log and current state
An event log stores each player action as a separate record and allows restoring the inventory at any point in time. Current state keeps a ready snapshot—cheaper to read, but change history is lost unless written separately.
A hybrid is more common: a snapshot as the source for sending to the client plus a log of recent operations for resolving disputed situations.
Record versioning—a version number for each change—enables rollback to a previous state and protects against reapplying the same operation.
| Option | When it fits | Limitations |
|---|---|---|
| Event log | Full history, complaint investigation, rollback needed | Volume grows, reading requires reassembly |
| Current state | Frequent reads, simple inventory | No history, rollback only from backup |
| Snapshot + log | Balance of read speed and traceability | More complex schema and data migration |
Where the boundary between client and server lies
The client renders the inventory and shows the result immediately, but is not the source of truth: any change is confirmed by the server.
The server validates the operation, locks the player's operations for the duration of the transaction, and only then commits the change—so two parallel requests will not deduct one item twice.
If confirmation does not arrive, the interface rolls back the displayed result and re-reads the state from the server.
Implementation stages: from operation audit to handover of policies
Implementing an inventory system starts not with code but with analyzing how items currently reach the player and what happens to them afterward.
We describe every operation—reward grant, purchase, trade, consumption, cancellation refund—and mark places where the balance can diverge: connection drop, repeated request, simultaneous actions from one account.
Audit of current operations and data model
- Collect a list of operations and rules: item limits, lifetimes, attachment to an event or season, who initiates the change—client, game server, or external service.
- Analyze the current data model: where state is stored, how items and stacks are related, whether there is a change log, and whether it can restore the inventory at any moment.
- Design the target schema: an operation log with a unique request key so resubmission does not grant an item twice, and locking rules for parallel purchases.
Testing for failures and repeated requests
- Run failure scenarios: connection drop at the moment of deduction, request duplication, simultaneous purchase of the last item, service crash between deduction and grant—the state must converge.
- Migrate the ledger to the new schema in shadow mode: old and new calculations run in parallel, discrepancies are compared row by row, and rollback is available until the switchover.
- Hand over the operations policy: discrepancy metrics, anomaly alerts, manual edit procedure with mandatory audit log entries, and a clear rollback to the previous version.
Handover package: data schemas, access policies, operational procedures
We assemble the handover package so that the client's team can evolve the inventory system without us: a new engineer understands the item structure within a day, and the on-call engineer knows what to do when balances diverge.
Everything described has been verified in a working environment, not reconstructed from memory at project exit.
- Item data schema: entities, relationships, stacking rules, instance identifiers, and prohibitions that must not be violated.
- Access policies and administrator roles: permissions matrix for granting, removing, and editing balances.
- Integrity test suite: double deduction, parallel grant, rollback of an unfinished transaction.
- Recovery and reconciliation documentation: recovery points, failure response procedure, convergence indicators.
- Operations procedures: key rotation, permission granting, incident escalation.
- Schema change log: versions, migrations, compatibility of previously saved inventories.
Access policies and administrator roles
We assign permissions by least privilege: a regular administrator grants items on request, a senior one edits balances, and schema changes are available to a narrow group.
Every action goes into an immutable log with the author—a dispute over "who granted it" is resolved in a minute.
Recovery and reconciliation documentation
We describe two scenarios: rollback to a consistent state and reconciliation after a partial failure. The procedure, responsible parties, and indicators by which the on-call engineer understands that the inventory has converged again are specified.
Case study: eliminated item duplicates and lost purchases under load
The project is a mobile game with an in-game economy: items, bundles, purchases with in-game currency and payments. They came to us after a series of incidents during seasonal events, when growing online numbers exposed a weak point in the inventory system.
What it was before: manual reconciliation and a flow of requests
Item accounting happened in two places: part of the state was kept in the player profile, part in the operation queue. If the connection dropped between deduction and write, the player could receive an item twice or lose a paid purchase.
Support collected complaints every week, and engineers manually reconciled the ledger with the operation log—reconciliation took a full working day, and up to half of discrepancies were found only through requests. In the first minutes of an event, the number of such complaints multiplied.
What it became after: metrics and mitigated risks
Item grants were moved to atomic transactions with an operation key: a repeated request does not create a second record but returns the result of the first.
The project runs on Unity, but we keep the server-side inventory independent of the client—a game update does not break accounting.
Based on the control period results: item duplicates in the ledger are zero, requests about lost purchases decreased by approximately six times, and automatic ledger reconciliation takes minutes instead of a working day.
The load peak passed without discrepancies between the ledger and the operation log. The mitigated risks are double grants on repeated requests, loss of a paid purchase on connection drop, and balance divergence between services.
Supporting sources are monitoring dashboards, the transaction log, and support request exports for comparable periods before and after.
How does an atomic transaction differ from record locking?
Record locking separates operations in time: the first thread captures the record, and the others wait for release. An atomic transaction is responsible for something else—a set of changes is applied in full or rolled back, without leaving half a state.
Therefore, the choice is not between them, but in which locks live inside the transaction and for how long.
When operations conflict, the pessimistic approach makes the second participant wait, and under mass operations response time grows with queue length—up to timeouts.
The optimistic approach does not wait: it reads the state with a version, checks it on write, and if the data has already changed, repeats the operation. The fast path is one pass; the expensive path is a retry.
The choice depends on the frequency of conflicts per row. As long as contention for one item is rare—rewards arrive in different slots—the optimistic approach gives zero waiting and spends almost no resources on retries.
If several threads constantly write to the same stack, retries come in an avalanche, and the pessimistic approach with short lock holding is more predictable.
For inventory, it is important that a trade, assembling an item from resources, and transfer between players run as one atomic transaction: a partially applied trade is worse than a failure.
We limit the number of retries, maintain an idempotency key against duplicates on request resubmission, and monitor the conflict rate—it tells us when it is time to change the schema.
Limitations and pitfalls: common technical questions
Before launch, technical doubts concern not item logic but how the new layer coexists with the running server. Below are the things that most often come up during estimation: enabling on a live project, accumulated duplicates, connection drops, migration, and access rights.
Can it be implemented without stopping the game?
Yes, no downtime is needed. The new layer is deployed as a separate service with its own data schema, and the old logic continues to serve the inventory.
Enablement happens behind a feature flag and initially for a subset of players—if checks diverge from expectations, the flag is switched back.
What to do with already accumulated duplicates?
They are resolved before enablement. Reconciliation runs through the operation log: for each position, the chain of grants is restored and one correct balance is determined.
The excess is deducted by a separate operation with an audit entry, so the history can be explained to the player and support.
What happens on a connection drop or request resubmission?
Each operation carries a unique identifier: a repeated request does not create a second item—the server recognizes it and returns the result of the first. The transaction is either confirmed in full or rolled back, so the state "deducted but not granted" does not occur.
Who handles migration, and how are rights separated?
We handle migration: we transfer balances, verify convergence before and after, and maintain a rollback path. The client needs to provide access to the storage and a person who confirms rules for disputed items.
We divide rights by role: support sees history but does not change balances; grants within the limit belong to economists; the item catalog belongs to administrators.
Let's discuss the task: what to send for estimation and a work plan
To come back with a work estimate rather than a range "from and to," we need source data on the inventory system: item grant and deduction rules, constraints on concurrent operations, target platforms. The more specific the inputs, the more accurate the implementation plan and team composition.
- Inventory rules: item categories, stacks, slot limits, attachment to character or account.
- Data schema and current storage: table structure, where state is stored, whether there is an operation log.
- Atomicity requirements: which operations must run in full—sale, trade, item creation, combat reward—and what happens on a connection drop.
- Load scenarios: peak number of concurrent players, operation frequency, seasonal spikes.
- Target platforms and client branches: where the app is already released, what restrictions stores have.
- Access: repository, test environment, export of anonymized data for hypothesis testing.
- Project constraints: deadlines, release staging, who on the client side makes decisions on game rules.
Then we assemble this into a work breakdown: first the data layer and transactional model, then server logic, then the client part and tests on concurrent scenarios. The output is a work estimate, a staged implementation plan, and a team composition for your scope. Describe the task—we will come back with an estimate and a plan.