LETOS

Context

LETOS explores the operational layer behind an e-commerce business: products, inventory batches, orders, cancellations, returns, and marketplace synchronization. These workflows share the same stock, but they do not always happen in the same system or at the same time.

The case study focuses on the backend decisions that keep those workflows understandable when traffic, concurrent updates, and third-party failures begin to overlap.

The catalog is what customers see. The stock ledger is what operations must be able to trust.

The core problem

Listing a product is straightforward. Preserving one reliable source of truth across sales channels is not. An order may arrive while another order is reserving the same batch. A cancellation may race with confirmation. A marketplace may accept a request but delay or lose its response.

The system therefore has to protect a few important invariants:

• Available inventory must never be consumed twice.
• Every quantity change must have an explainable business reason.
• Order transitions must be explicit enough to retry safely.
• Integration failures must not silently corrupt internal state.

System design

Inventory is a ledger, not just a number

A single quantity field is convenient, but it cannot explain how stock changed. LETOS treats inventory movements as first-class records: receipt, reservation, release, sale, return, and adjustment. The current balance can be read quickly while the movement history remains available for reconciliation and support.

Batch-level allocation adds another useful boundary. It preserves the relationship between incoming stock and outgoing orders, making partial fulfillment and later investigation much easier to reason about.

Order flow uses explicit transitions

The order lifecycle is modeled as a series of deliberate state changes rather than a loose set of updates. Reservation, confirmation, cancellation, and return each own their inventory effect. This keeps stock behavior close to the business action that caused it.

Marketplace integrations are unreliable boundaries

External channels are treated as systems that can be slow, unavailable, or inconsistent. Integration work is isolated from the internal model, requests are designed to be safely retryable, and synchronization state is visible enough to diagnose without guessing.

Hard engineering problems

Concurrent reservation

Two valid requests can read the same available quantity. The important operation is not the read; it is the guarded write. The design keeps validation and mutation inside the same transactional boundary so only one request can claim the final unit.

Cancellation and compensation

Cancellation is not simply a status label. It may need to release a reservation, record a movement, and schedule a marketplace update. Those effects must be idempotent so a retry does not return the same stock twice.

Operational debugging

When a support question arrives, the system should answer three things quickly: what changed, why it changed, and which workflow caused it. Correlation identifiers, structured logs, explicit transitions, and the movement ledger form that audit path.

My role

As the backend engineer, I focused on the domain model, transactional boundaries, and the shape of integration workflows. The work connected API behavior to database guarantees so reliability did not depend on controllers remembering a fragile sequence of steps.

The implementation stack centers on .NET, EF Core, and MySQL, with Nginx at the application boundary. Framework choices mattered less than keeping responsibilities visible: domain state inside the core, persistence rules near the data, and channel-specific behavior at the edges.

Design principles

• Make invalid states difficult to represent. Use explicit transitions and constraints.
• Record business meaning. A movement reason is more useful than a mysterious delta.
• Assume every external call can fail. Keep retries safe and integration state observable.
• Optimize for investigation. Operational software must explain itself after the request ends.

What I learned

The database model and movement log are the backbone of an operations product. Clear audit paths shorten debugging, but they also improve product decisions: teams can see which state they are in, what action is safe next, and where an integration stopped.

The broader lesson is that backend reliability is rarely one clever algorithm. It is the result of many explicit boundaries working together: transactions, idempotency, state transitions, movement records, and useful logs.