VenduSys
Home/Architecture
Architecture · Deep-dive

How VenduSys
actually runs.

VenduSys is not a monolith and not a swarm of microservices. It is a small set of named services with explicit contracts, sitting behind one consistent API, deployed in the EU. This page is the honest map.

Runtime
Node 24 · Edge functions
Storage
Postgres (Supabase) · pgvector · S3-compat
Deploy
Vercel + dedicated EU clusters
Open standards
OpenAPI · GraphQL · OAuth · OIDC
Audit
Every move is replayable
Get a walkthrough →
Regenerative commerce. One point of truth.
Fig. 01 — How VenduSys fits together
Case-to-Core℠
Ecosystem layerPeople, roles and departments collaborate around the customer to create value.
Customer
Marketing
Sales
Support
Finance
Operations
Partners
Surface layerFour portal types on one foundation — from a single site to a whole network operating together.
Website · portal
VenduSite
A website with commerce capabilities — content, accounts, support and services in one portal.
Webshop · portal
VenduStore
A webshop with website capabilities — catalogue, checkout and fulfilment, without losing the story.
Marketplace · portal
VenduMarket
A marketplace with commerce capabilities — many sellers discovering, transacting and collaborating.
Network · portal
VenduNet
A network organization — many parties operating as one shared value network, not one corporate.
Operational layerHow the work actually runs — cases, workflows and handoffs coordinated across every role.
VenduOpsThe operating spiral
Cases & requestsWorkflowsHandoffs & SLAsCoordinationCollaborationService & success
Organizational layerThe shape of the network — tenancies, nodes and the stakeholders connected upstream and downstream.
VenduOrgThe network structure
NetworksTenanciesNodes & hierarchyRoles & permissionsUpstream stakeholdersDownstream stakeholders
Technology layerA composable stack that integrates everything on a single point of truth.
VenduStackThe modular technology foundation
Identity & Roles
Portals & UX
Data & Single Point of Truth
Workflows & Collaboration
Integrations & APIs
Security & Compliance
Analytics & Insights
Automation & AI
SecureScalableComposableAPI-FirstCloud-Native

Case-to-Core℠ is the learning spine through which an ecosystem becomes progressively intelligible to itself — and through which signals, knowledge gaps, uncertainties and possibilities continuously provoke new inquiry.

One system. All roles. Shared truth. Better customer value.
The stack

From the network
to the ledger.

Each layer is a small, named service with an explicit contract. You can adopt the whole stack, or replace any single layer with your own and keep the rest.

Edge
CDNEdge functionsBot mitigationRate limit
API surface
GraphQL gatewayREST gatewayWebhooksSSE / streaming
Identity
Identity graphKYB / KYCPoliciesAudit log
Catalog & pricing
Thing graphVariants & bundlesInventory poolsPricing enginePromotions
Orchestration
Workflow engineSchedulerEvent busSide-effects queue
Money
LedgerPayment routerEscrow / payoutTaxRefunds & disputes
Intelligence
DecisioningEmbeddingsRecommendationsFraud signals
Storage
PostgrespgvectorObject storageCDC streamDWH export
Data model

Four entities.
Everything else derives.

We described the model in a separate post. The short version is below.

A / Party

Party

People, organizations, agents. Buyers, sellers, operators, partners — all projections of the same record. Identity is a graph, not a type.

person · org · service · machine
B / Thing

Thing

Anything offered or owned. Products, licenses, services, subscriptions, assets, time. Variants and bundles ride on top.

SKU · entitlement · capacity
C / Move

Move

Events that shift value or rights between parties. Orders, returns, renewals, transfers and disputes are all moves with state machines.

order · transfer · refund · renew
D / Entry

Entry

Lines in the ledger. The model is designed so every Move emits Entries, with reports and balances derived from them.

debit / credit · account · journal
Workflow engine

Every flow
is observable.

Listings, approvals, payouts, returns, renewals — modeled as code or visual graphs. Branch, retry, replay, audit. State is persisted; nothing is fire-and-forget.

VenduSys Workflow · Runtime view
Fig. 03
Triggers
  • EVT Domain event
  • CRON Scheduled
  • API Direct invoke
  • WHK External webhook
  • CDC Database change
Workflow runtime
  • Compile graphPARSE
  • Persist stateSTATE
  • Dispatch stepsRUN
  • Handle retriesRETRY
  • Emit audit logAUDIT
Effects
  • DB Ledger entries
  • PAY Payment / payout
  • MSG Notification
  • EXT Connector call
  • EVT Downstream event
Operational

What it takes to run.

The boring details — hosting, residency, RPO/RTO, observability. The things that matter when something goes wrong at 2 a.m. on a Sunday.

Hosting
Vercel for the API edge · dedicated EU clusters for stateful services (Paris)
Storage
Postgres (Supabase) with logical replication · S3-compatible object storage · pgvector for embeddings
Replication
Multi-AZ within region · cross-region read replicas · CDC stream to warehouse
Failover
RPO 0 · RTO 5 minutes for ledger & identity · 15 minutes for catalog
Observability
OpenTelemetry by default · per-tenant traces · structured audit log · workflow replay
Encryption
TLS 1.3 in transit · AES-256 at rest · BYOK on Enterprise · per-tenant key isolation
Residency
EU by default · region pinning on Scale/Enterprise · audit-friendly data exits

Want the
full walk-through?

Architecture sessions with the founding team.
Book a session →Read the data-model post →