Freelance Backend EngineerAurNexaAug 2026 - now
AurNexa marketplace backend
Backend design for a pre-launch B2B construction-materials marketplace: 9 bounded contexts, 5 in the MVP.
✓ VERIFIED9
Bounded contexts, 5 in the MVPFrom the backend design.✓ VERIFIED0
Separate message brokersThe outbox runs on a PostgreSQL queue (SKIP LOCKED).The problem
Orders touch payment and logistics vendors that may change. A failure halfway through an order must not leave it half-paid or half-shipped.
What I built
I split the backend into 9 bounded contexts, with a provider registry so payment and logistics vendors plug in behind stable interfaces. Orders and payments run as a saga with compensating steps. Events go through a transactional outbox on PostgreSQL.
Architecture
Order flow
Each step has a compensating step that undoes it.
01
OrdersRuns the saga.02
PaymentsVendor from the provider registry.03
LogisticsVendor from the provider registry.04
OutboxPostgreSQL queue, SKIP LOCKED.Orders → Payments · refund if a later step failsOrders → Logistics · after paymentOrders → Outbox · written in the same transaction
Decision log
What I chose, and what I gave up
01Saga with compensating stepsover two-phase commitPayment and logistics are external vendors.
External vendors cannot take part in a two-phase commit. Each saga step can be undone if a later one fails.
+ An order is briefly in an in-between state− Holding locks across vendors
02Transactional outbox on PostgreSQLover a separate message brokerThe product has not launched yet.
Events are saved in the same transaction as the data, with one less system to run.
+ Throughput is limited by PostgreSQL− Running a broker before launch
Scaling story
How it grew
01
Contexts first9 bounded contexts designed, 5 in the MVP.
Next case studyGaming platform performanceSlow PostgreSQL queries on high-traffic endpoints, fixed with query plans and new indexes.