Cartlabs
Loading
ABOUT / ENGINEERING

A multi-vendor marketplace case study.

Cartlabs is a deployable full-stack system running on self-hosted Kubernetes. I built it as a hands-on lab for experimenting with infrastructure and backend tools while solving real systems problems such as transactional checkout, authorization, service boundaries, and operational recovery.

Next.js + GoPostgreSQL + RabbitMQSelf-hosted k3s
Service boundary

Modular core, measured extraction.

The commerce core stays transactional. Search is the first extracted boundary because it tolerates eventual consistency.

Runtime shape

Request, state, events, extraction.

Deployables run inside self-hosted k3s. Synchronous commerce stays authoritative in PostgreSQL; projections and delivery move through explicit boundaries.

HTTP / gRPCversioned eventsfinal authority
Deployment boundarySelf-hosted k3s + Helm
05 deployables

web · api · worker · search · mock payment

01

Request path

Browser traffic stays REST at platform edge.

ClientBrowserSame-origin app traffic
HTTP
WebNext.jsGenerated TS + REST proxy
REST
CoreGo REST APIModules + authorization
02

State plane

Commerce state and short-lived coordination.

Core dependencyGo REST APIQueries, writes, visibility checks
SQL + cache
AuthorityCatalog PostgreSQLOrders, inventory, users, stores
CoordinationRedisCache, limits, short-lived state
03

Async delivery

Committed facts leave the request path safely.

Commit boundaryTransactional outboxPublishes after database commit
publish
BrokerRabbitMQRetries + dead-letter queues
consume
RuntimeGo workerIdempotent jobs and events
04

Search boundary

Extracted retrieval, PostgreSQL visibility authority.

CallerGo REST APIFilters final visible records
protobuf / gRPC
Independent serviceSearch microserviceCandidate retrieval + projection owner
projection
Read modelSearch PostgreSQLText projection, not commerce authority

Worker-published catalog events update the projection. If gRPC is unavailable, API falls back to PostgreSQL text search.

05

Payment callback

External behavior stays behind a signed interface.

Gateway simulatorMock paymentIntent completion + retryable callback
signed webhook
VerifierGo REST APISignature, amount, event dedupe
Observability railOpenTelemetry + Prometheus/GrafanaTraces, metrics, structured logs, health probes.
Operational boundaryHelm-managed recoveryMigrations, readiness checks, and restartable services.
Transaction path

Checkout under contention.

One checkout crosses inventory, payment, orders, and async delivery without losing state between boundaries.

05 boundaries
  1. Read authoritative stateReload published products, approved stores, prices, and available stock from PostgreSQL.
  2. Reserve under lockUse row-level locks and atomic updates so concurrent checkout cannot oversell inventory.
  3. Create the order graphCreate one parent purchase and one seller order per store, with immutable item snapshots.
  4. Verify paymentValidate the mock provider signature, timestamp, reference, amount, currency, and event ID.
  5. Publish and fulfillCommit domain state with an outbox fact, then let workers deliver events while sellers advance owned orders.
Feature surface

What to inspect

The mechanics that make this more than a catalog mockup.

06 areas
Atomic checkoutPostgreSQL transactions reserve SKU inventory and reject underflow before creating purchase state.
Idempotent mutationsIdempotency keys and provider-event deduplication make retries safe across checkout and payment.
Seller isolationTransport and domain checks enforce role boundaries and prevent sellers from crossing store ownership.
Order state machinesPurchase and seller-order transitions reject invalid moves with explicit conflict responses.
Resilient searchThe gRPC search service retrieves matching product IDs; PostgreSQL applies visibility and remains the fallback.
Verified reviewsOnly buyers with delivered items can review, and duplicate submissions are rejected.
System qualities

Built for inspection.

Cross-cutting choices keep behavior testable and explainable.

04 areas
SecurityArgon2id passwords, short-lived access tokens, rotating refresh cookies, rate limits, and immutable admin audit facts.
ContractsOpenAPI is the source of truth for generated Go and TypeScript types. CI rejects contract drift.
ObservabilityOpenTelemetry traces, Prometheus metrics, structured logs, and dependency-aware health probes cover runtime behavior.
DeploymentDocker images and Helm charts run the stack on a self-hosted single-node k3s cluster with migrations, probes, and optional telemetry.
Scope

Explicitly not production commerce.

The project demonstrates credible system behavior while keeping external integrations and operational scope honest.

  • Payment is simulated; no live financial provider is connected.
  • IDR only; shipping, email, refunds, and promotions are deferred.
  • Search is a read projection; PostgreSQL remains final authority.
  • Seeded demo data is resettable and quick-login is opt-in.