Zyzy / Minions Shop

The backend owns the checkout calculation

The storefront presents variants, stock limits, a cart, and discount quotes. The server validates the request and calculates the order rather than trusting a browser total. Within the checkout transaction, it checks the idempotency key and locks the relevant stock rows before writing the order.

That connects two practical problems: a repeated submission should not create a second effect, and concurrent customers should not independently assume the same stock is available. The implementation uses PostgreSQL transactions and row locking to address those boundaries.

A historical sale needs historical costs

Product purchase costs and public selling prices are separate. When the application creates an order line, it stores the unit selling price, purchase price, quantity, and line cost for that transaction.

Those snapshots matter when a catalog price changes later. Recalculating an old order from today's product cost would change the apparent result of a past sale. The accounting queries use order-line snapshots to summarize cost of goods and gross profit for eligible orders.

Administration is part of the application

The admin interface includes product editing, inventory, order workflows, discounts, review moderation, and settings. Authentication uses server-side sessions and protected routes; request validation and authorization stay in the API.

Numbered migrations, seed data, and deployment documentation support maintaining the application alongside its storefront and administration screens.

Prototype status

The current repository uses illustrative catalog and cost data, with checkout disabled by default until the catalog is verified. Online payment is outside the current implementation. Customer accounts and advanced reporting appear in the roadmap rather than being silently presented as delivered features.