Vendryx Commerce

What I set out to build

Vendryx is a hosted commerce system for small merchants, with a Rust backend, PostgreSQL database, merchant administration, and storefront applications. The engineering question is not just how to implement carts and orders. It is how to isolate merchants safely within one shared application and database while keeping workflows such as checkout, payments, inventory, and settlement coherent.

This is private company-related work. The case study intentionally does not publish source code or commercial configuration.

One concrete design decision: fail-closed tenancy

I chose database-enforced tenant isolation as a backstop against application mistakes. The repository contains a SQL migration named 20260819000003_enable_rls/up.sql that:

• Enumerates tenant-owned application schemas.
• Enables and forces PostgreSQL row-level security on tenant-owned tables.
• Installs a tenant policy using tenant_id = current_setting('app.tenant_id', true).
• Applies WITH CHECK to protect writes, not only reads.

Why FORCE ROW LEVEL SECURITY matters: PostgreSQL table owners can ordinarily bypass RLS. In a shared-tenant system where the application role may own the tables, simply enabling RLS is insufficient. Forcing it makes isolation apply to the owner as well.

Why missing_ok = true matters: If no tenant context is set, current_setting returns null. Equality against null does not pass the policy, so the intended default is no visible tenant rows. This is defense in depth, not a replacement for checking tenant context in the service layer.

The repository also has isolation-checking scripts and a staged CI definition that separates static checks, integration tests, end-to-end checks, and release readiness.

System boundaries

The codebase separates Rust modules, merchant administration, storefronts, and an operator control plane. The company-wide control plane later moved to a separate project, Space. That separation keeps merchant-facing behavior distinct from customer subscriptions, provisioning, and internal company operations.

Those boundaries add engineering cost: authentication, configuration, tenant context, and data migrations must agree. The complexity only earns its place if the resulting system is safer to extend and test.

What is implemented versus what is not proved

The repository's September 13 status ledger marks its Phase 3 commerce tasks complete. It separately records a partially complete transitional control plane, including API routes that still need real backing behavior. The latest visible CI and nightly workflow runs, on October 8-9, 2026, failed.

A completed internal task checklist does not establish live customer traffic, healthy production deployment, payment-provider certification, or current green CI. I do not present these as verified outcomes.

What I would show in a technical interview

I can walk through the RLS migration, the tenancy model, why an unscoped query should fail closed, the distinction between a merchant service and an operator control plane, and the sequence of checks needed before claiming release readiness. An interviewer can challenge whether these design choices are justified and whether they survive integration and deployment.

Status: active private engineering project. Database-layer isolation implementation is observable in the repository; operational scale and complete release readiness remain unverified.

Evidence: migrations/20260819000003_enable_rls/up.sql, .github/workflows/ci.yml, docs/STATUS.md (last consolidated September 13, 2026).