Pontefy: Multi-Vendor E-Commerce Platform

What the platform does

The platform covers the full commerce lifecycle end to end: product and category management with rich attribute definitions, inventory tracking across warehouses, the order and shipping lifecycle from cart to delivery, customer and campaign management, and dedicated vendor panels. Integrated payment and subscription modules sit alongside it, so recurring commerce is part of the same system rather than a bolt-on.

The architecture scales horizontally and the frontend layer is customizable, which is what makes fast time-to-market realistic even in high-traffic scenarios — the storefront can be shaped per brand without forking the commerce core underneath it.

Capabilities

Pontefy is in development. The list below is the capability set we are building toward; it describes the design, not a finished product.

• Multi-vendor support with dedicated vendor panels and onboarding flows
• Product and category management with rich attribute definitions
• Inventory tracking with real-time stock across warehouses
• Order and shipping lifecycle from cart to delivery, with carrier integrations
• Customer and campaign management for targeted promotions and loyalty
• Integrated payments and subscriptions for recurring commerce
• Customizable storefront over a flexible frontend architecture
• B2C, B2B and marketplace models from a single platform

How it is built

• .NET microservices backend built for horizontal scaling
• PostgreSQL for transactional data, with read replica support
• API-first architecture, so headless commerce is a first-class scenario
• Event-driven order processing for high-throughput operations

Three business models on one model means pushing the differences into data

B2C, B2B and marketplace only stay configurations of one system if the things that vary between them are data rather than branches in the code. The one that decides whether this works is pricing. There is no price column: a price is resolved through a context — customer or customer group, contract, quantity break, currency, tax treatment — so a B2B contract rate and a B2C list price are the same lookup with different inputs, and neither is a special case of the other. Tax display follows the same rule: whether prices are shown inclusive or exclusive belongs to the context, not to the storefront, which is why the same catalogue can serve a consumer shop and a business account without two catalogues.

Inventory is a ledger, not a counter

Stock is recorded as movements and reservations rather than as a number that gets decremented. A cart hold, a placed order, a warehouse transfer and a return are four different claims on the same physical quantity, and a single counter cannot represent them or answer why it has the value it does. Available quantity is derived: on hand minus outstanding reservations. Reservations expire, which is what stops abandoned carts from quietly consuming sellable stock.

Overselling is a race, and races have to be settled where the write happens. The reservation is taken in the database with the constraint that makes the conflicting case fail, not in application code that reads a value and then writes one — the read-then-write version is correct in testing and wrong under exactly the traffic the platform is built for.

The order lifecycle is a state machine over systems it does not control

Payment authorization, warehouse fulfilment and carrier handoff are all external and all asynchronous. The order therefore holds its own state and reconciles theirs, rather than treating a call to any of them as the source of truth. Partial fulfilment is why an order is a parent with per-line-group shipments underneath it — and once that shape exists, a marketplace order split across three vendors is structurally the same thing as a B2C order shipping from two warehouses. That is the concrete reason marketplace did not need its own order system: the split was already in the model for a reason that had nothing to do with vendors.

Vendor panels follow from the same decision. A vendor gets a scoped view over the shared catalogue and the order lines that belong to it, not a separate application with its own store to keep in sync.

The transaction is kept small on purpose

Placing an order commits two things: the reservation and the order itself. Everything else — stock movement posting, confirmation notifications, invoicing, vendor notification on a marketplace order — is a consumer of the resulting event. The alternative, holding a database transaction open across a payment call and a carrier API, means checkout availability becomes the product of every external system’s availability, and a slow carrier endpoint takes the shop down.

The event is written in the same transaction as the order and dispatched from there, so a process that dies immediately after commit still produces the downstream work. Consumers are idempotent because they will see the same event more than once; that is a cost of the arrangement, and it is cheaper than the alternative.

Read and write paths are separated by query, not globally

Catalogue browsing is overwhelmingly read traffic and tolerates data that is a moment old. Checkout does not: anything that decides money or stock reads the primary. So the replica decision is made per query and made explicitly, rather than being a connection-level setting that quietly routes a stock check to a replica and sells something twice. Being explicit about which reads may be stale is what makes read replicas a scaling tool instead of a source of intermittent, unreproducible bugs.

Headless means the rules stay on the server

Per-brand storefronts are separate frontends against the same commerce API rather than forks of the platform, which is what allows a storefront to be shaped for a brand without the core diverging per deployment. The constraint that comes with it: campaign and promotion evaluation stays server-side. A discount computed in the browser is a discount the customer can choose, so the storefront asks what the price is and renders the answer — it never derives it.