Commerce platform / systems architecture
A commerce platform
built end to end.
A TypeScript commerce platform I designed and built end to end: separate shop and admin products, a gateway-led service architecture, and an extension runtime for realistic local HTTPS development.
What it is
Commerce is the interface. The platform is the work.
Emporion is a commerce platform I designed and built from the ground up. The customer shop and the admin backoffice are separate products, but they rely on the same set of rules, services, data, and infrastructure.
Shop and admin solve different jobs without becoming two disconnected applications.
The gateway handles the edge; domain services keep the decisions and their data ownership explicit.
MongoDB remains the source of truth, while Redis is used only for short-lived acceleration.
Docker Compose, HTTPS ingress, health checks, release flows, and backups are part of the platform itself.
Platform surfaces
Four surfaces, one flow.
Shop
The customer-facing surface for browsing products, managing a cart, and moving through checkout.
Admin
A separate backoffice for catalog, content, media, orders, and the operational work around them.
Gateway
One public boundary for routing, authentication policy, security headers, and service access.
Domain services
Auth, catalog, orders, CMS, status, and plugin capabilities with clear ownership.
Services and ownership
Each service owns a decision.
The gateway is the front door, not a dumping ground. Behind it, each service owns one part of the commerce domain. That keeps the boundaries practical: identity does not own orders, payment state does not leak into the catalog, and the storefront does not need to know how the backend is assembled.
API gateway
The single public boundary: routing, authentication policy, security headers, and access to the services behind it.
Auth service
Identity, sessions, capabilities, and the separation between customer access and administration.
Catalog service
Products, variants, categories, media, facets, and the product types that make the catalog extensible.
Orders service
Cart and checkout state, invoices, payment transitions, and the webhooks that bring those transitions back into the platform.
CMS service
Pages and content as a proper domain, so editorial data does not leak into storefront or admin code.
Status service
Health and runtime signals that make the state of the platform visible during development and delivery.
Plugin manager + runner
The registry, release artifacts, and controlled execution path for capabilities that extend the core platform.
Extension model
The platform can grow without losing its shape.
Extend the catalog
Product types, fields, and renderers can grow without turning every new commerce idea into a storefront rewrite.
Keep extensions explicit
The plugin manager owns registration and release artifacts; the runner keeps execution behind a defined capability boundary.
Share the contracts
Common packages keep configuration, types, validation, and runtime conventions aligned across the monorepo.
Built for real conditions
The hard parts are part of development.
Real hosts
Shop, admin, and API use separate HTTPS subdomains, so browser behavior is closer to a deployed system.
Real sessions
Cookie scope, Secure flags, SameSite behavior, and separate admin/customer sessions can be tested where they actually run.
Real edges
Payments, redirects, webhooks, CSP, proxy routing, health checks, and release checks are part of the same loop.
The result
Built by one person, across every layer.
Emporion started as an idea for a commerce product and became a full systems exercise. I kept the product, code, infrastructure, and quality work in the same line of sight, so every architectural decision could be tested against an actual user flow.
Product decisions, architecture, implementation, infrastructure, security, testing, and delivery all belong to the same project.
The shop, admin, gateway, services, and extension runtime can evolve without hiding their responsibilities from one another.
HTTPS, cookies, payments, health checks, release flows, and failure states are part of the experience being built.