Store architecture

Technology.

A shopper taps the last item in stock. The storefront responds, the engine checks the price, and the store records the order. Here’s how the pieces work together.

Follow an order

Vue storefrontCheckout engineOrder records

Ⅱ Pause motion▷ Resume motion

Native checkout

Who gets the last one?

Two shoppers see the same jacket. Follow one of them from the product page to the order record.

Explore the steps of a purchase

Browse
Reserve
Record

Open a product in place.

ShopiChain’s Vue storefront updates supported catalog and product views without reloading the whole page. Inside a Winkdom site, Winkdom handles that navigation. The product has a shareable URL in either case.

Seeing one jacket on screen leaves it available to other shoppers.

Check the price and reserve stock.

At native checkout, ShopiChain reads the current price for the selected size, applies eligible discounts and checks managed inventory. If the other shopper already reserved the last medium, this order cannot claim it.

The store makes the decision using its current records.

Keep one order through a retry.

Native checkout saves the order with its line prices and stock reservation in a database transaction. If the connection drops after the order is created, a retry with the same checkout key returns that order. Payment confirmation is a separate step.

This flow describes ShopiChain’s native WordPress engine. A connected engine follows its own checkout rules.

Data & access

Where the records live.

Your choice of engine, payment provider and search service determines who processes each part of a sale.

Store database: The native WordPress engine keeps its carts, orders and managed stock reservations in the store database. A merchant can export catalog data as CSV. Moving order history, subscriptions or licenses calls for a separate migration check.
Payment provider: A configured gateway receives the information it needs to process a payment. With hosted checkout, the buyer enters payment details with that provider. Its transaction records and retention rules also apply.
Search index: An enabled search worker receives the product fields selected for indexing. A search update can run separately from checkout. Order and payment processing stay with the commerce engine.

Optional workers

Give search its own worker.

When a product changes, updating its search entry is a separate job. Remote transfer is off by default. The merchant chooses which supported jobs may leave the store.

Store queue

WordPress keeps the job and its status. Supported work can stay local.

Signed request

If enabled, Offload sends the search job to a compatible worker. The merchant can operate that worker with credentials kept on the server.

Search update

The reference worker can add, update or remove a product document in Typesense. Checkout continues to use the store’s own price and stock records.

In development

A standalone path.

ShopiChain is developing a Go commerce engine backed by PostgreSQL. The prototype handles draft orders and test payments. A production serverless store and wider integration with Winkdom CMS and EmDash are planned.

Explore migration routes

Go: Small, independently deployable services can handle storefront requests and background jobs. A catalog traffic spike and a busy checkout can have different capacity needs.
PostgreSQL: Transactions keep related changes together. For commerce, that means an order and the changes it depends on can succeed or roll back together.
Scaling: The target is to add compute as demand grows. Launch testing needs to measure peak checkouts, database connections and queue delays, including the time it takes to recover after a spike.