Online store architecture
Online store architecture: the decisions that matter
The architecture of an online store comes down to 1 choices: atomic conditional UPDATE plus short reservations to prevent overselling. Each is explained below with the alternatives that were rejected and what you accept by choosing it.
Last checked
Atomic conditional UPDATE plus short reservations to prevent overselling
Situation: Concurrent buyers, retries and abandoned checkouts make read-check-write stock logic oversell the last unit, which costs refunds and trust.
Choice: Reserve stock with one conditional UPDATE keyed on on_hand - reserved >= qty at checkout, time-box the reservation with a 15-minute expiry swept by a job, and commit on the paid webhook, with CHECK constraints as the backstop.
- Rejected: Decrement on cart add: abandoned carts starve real buyers.
- Rejected: Read stock then write: race condition, oversells under load.
- Rejected: Row locks held across the payment step: contention and lock timeouts.
- Consequence: Abandoned checkouts hold stock for up to 15 minutes.
- Consequence: A hot SKU serialises on one row, bounded by rate limits.
- Consequence: Every stock change is in an append-only movement ledger.
How the data is indexed
Indexes are chosen from the questions the app asks most often. Each line below names a table and the question its main index answers.
- products: unique (handle) — product URL slug.
- product_variants: unique (sku) — SKU lookup and CSV import upsert key.
- product_media: (product_id, position) — gallery order.
- collections: unique (handle) — collection URL.
- collection_products: unique (collection_id, product_id) — a product is in a collection once.
- inventory_levels: unique (variant_id, location_id) — one row per variant and location, target of the atomic reserve.
- inventory_reservations: (status, expires_at) where status = 'active' — expiry sweep releases abandoned checkouts.
- inventory_movements: (variant_id, created_at DESC) — stock history for one variant.
What Forge64 provides underneath
Forge64 matches your description to one of 12 reference architectures, writes the plan and data model into the project, generates the app, and runs a quality gate over the code before you see it. Each app gets its own Postgres database and sign-in with no per-user fee. Hosting on Forge Cloud and Forge Payments are rolling out.
This is a reference design for the category, not a promise that every item is generated today. Built-ins such as email, background jobs, file uploads and search are coming soon, so anything here that needs them is something you add yourself for now.
FAQ
- What is the most important architecture decision for an online store?
- Atomic conditional UPDATE plus short reservations to prevent overselling. Reserve stock with one conditional UPDATE keyed on on_hand - reserved >= qty at checkout, time-box the reservation with a 15-minute expiry swept by a job, and commit on the paid webhook, with CHECK constraints as the backstop.
- Do I have to make these decisions myself?
- No. Forge AI plans them from your description and writes the decisions into the project as architecture records you can read and change.
- What do the alternatives cost me?
- Each alternative is listed with its drawback in the sections above.
Build your app with Forge64
One prompt to a running app with auth, database, hosting and payments. Start free, no credit card required.
Start building for free