Designing a real-time stock control system on AWS Lambda
When you sell the same bottle of perfume across 23 stores inside a single airport, "how many do we have left?" stops being a simple question. A passenger can buy the last unit at one gate while another is reaching for it two terminals away. Get it wrong and you either oversell stock you don't have, or you hide stock you could have sold.
This is the problem we solved while building the Stock Control System (SCS) for Unifree's duty-free operation at Istanbul Grand Airport. Here's how we approached it — and what I'd tell any founder facing a similar "shared inventory in real time" problem.
Why serverless, and why event-driven
The load profile of an airport is spiky by nature. Flights cluster, terminals empty and fill, and the system sits idle for stretches in between. Provisioning servers for the peak means paying for the trough. AWS Lambda let us scale with demand and pay for what we actually used.
But the bigger decision was making the system event-driven. Every sale, return, and restock is an event. Instead of a single service trying to read-modify-write a shared counter (and fighting over locks), each event flows through a pipeline that updates inventory state and fans out to whoever needs to know.
The trade-off nobody mentions
Real-time inventory has an uncomfortable truth: you can have accuracy or you can have availability, but at the edges you have to choose. When two registers commit a sale to the last unit within the same second, something has to give.
We leaned on idempotent event processing and a single source of truth for the count, accepting that the UI might show a number that's a beat behind reality rather than risk a double-sell. For a duty-free shop that's the right call — a momentarily conservative count is far cheaper than a customer at the gate holding a receipt for something that isn't there.
What I'd tell a founder
If you're building something with shared, contended state — inventory, seats, limits, balances — three things matter more than your choice of framework:
- Model it as events, not as a number you mutate. The number is a projection; the events are the truth.
- Decide your failure mode on purpose. Oversell or undersell? Stale read or blocked write? Pick before traffic picks for you.
- Make every handler idempotent. Retries are not an edge case in distributed systems; they're Tuesday.
The serverless part is almost incidental. The hard part — and the part worth getting right — is being deliberate about what "correct" means when two truths collide.
This is the kind of problem I help founders and teams work through. If you're staring at a contended-state system that needs to stay correct under real load, let's talk.