Design a Vending Machine System

A vending machine sounds simple: put in money, press a button, get a snack. But when you manage a fleet of 10,000 machines across a country, the real challenges emerge: how do you guarantee that payment and dispensing happen atomically? What happens when the machine loses network connectivity? How do you prevent two people from buying the last item simultaneously? This is not a toy problem. It is a distributed embedded system with real-money transactions and physical hardware in the loop.

Functional

Product selection and purchase: Users browse available products on a touchscreen display, see prices and stock availability, select a product, and complete a purchase. The machine guides the user through the entire transaction from selection to dispensing.

The capacity numbers for a vending machine system are modest per machine but add up quickly across a fleet. The key insight is that the individual machine is not the bottleneck. The central cloud backend that aggregates data from thousands of machines is where capacity planning matters.

Traffic

Per machine: 200-500 transactions per day in a high-traffic location (office lobby, airport terminal). That translates to roughly 0.003-0.006 transactions per second per machine. A single machine is never a throughput challenge.

The vending machine system has two API surfaces: the local API running on the machine itself (handling user interactions and hardware control) and the cloud API that connects machines to the central backend. Understanding both is important because the machine must function independently when the cloud is unreachable.

Machine-Side APIs (Local)

1GET /products
2Response: 200 OK {
3products: [
4{
5product_id: string,
6name: string,
7price: number,
8image_url: string,
9quantity: number,
10available: boolean
11}
12]
13}

The vending machine system stores data in two places: locally on each machine (for offline operation) and centrally in the cloud (for fleet management and analytics). Understanding why both are needed is key. A machine that cannot sell products during a network outage is a broken machine.

Local Storage (On-Machine)

Each vending machine runs a lightweight embedded database (SQLite) that stores the working data needed for independent operation:

The architecture has two layers: the on-machine system that handles real-time user interactions, and the cloud backend that manages the fleet. These two layers communicate through periodic sync rather than persistent connections, a deliberate choice for reliability over real-time visibility.

On-Machine Components

Two request flows define the system: the purchase flow (the customer's experience) and the inventory sync flow (the operator's visibility). Understanding each step, and where failures can occur at each step, reveals why the transaction state machine exists.

Purchase Transaction Flow

The core engineering challenge (the GATE of this problem) is ensuring that payment and dispensing happen atomically: no scenario should result in money taken without a product delivered, or a product dispensed without payment. This sounds simple but becomes complex when you consider every failure point: payment gateway timeout, dispensing jam, power loss, network outage, and concurrent requests for the last item.

Transaction State Machine

Every architectural decision in this system involves a trade-off between reliability, complexity, and cost. Understanding these trade-offs shows interviewers that you made deliberate choices rather than adopting patterns blindly.

Local Processing vs. Cloud Processing

Local processing (transactions on the machine): The machine handles the complete purchase cycle without cloud involvement. This enables offline operation and sub-second transaction completion. The cost is duplicated logic (the machine runs its own inventory, payment, and state management) and delayed visibility (the cloud only sees data after sync).

The system's reliability depends on handling every failure mode without losing money or products. Each failure scenario maps directly to a state machine transition designed to handle it.

Dispensing Mechanism Jam

Scenario: A user pays for a bag of chips. The motor activates but the bag is wedged against the coil and does not drop.

These improvements extend the system beyond basic vending without changing the core architecture. Each builds on the existing on-machine and cloud infrastructure.

Remote Monitoring and Analytics Dashboard

The current system syncs basic health and inventory data. An enhanced dashboard would provide real-time fleet visualization on a map, historical sales trends per machine and product, heat maps of peak usage times, and predictive restocking routes that optimize technician schedules based on consumption patterns. This uses the existing sync data pipeline: a separate analytics service consumes the transaction log and computes metrics stored in a time-series database for fast dashboard queries.