Skip to main content
Stacklane

Real-time matching, PostGIS + WebSockets + queues, at the cadence supply and demand actually move.

Marketplaces match when both sides show up at the same time. We build the matching engine on Postgres (with PostGIS where geography matters), stream matches over WebSockets, and queue the slow paths so the request loop never blocks on a vendor API. The pattern survives growth from 50 active sessions to 50,000 without re-platforming.

What we build

  • PostGIS for the geographic queries

    Where the marketplace has a location dimension (rides, delivery, lessons, services), PostGIS handles the spatial queries on the same database the rest of the marketplace uses. No separate geo service, no Elasticsearch tier, no managed location vendor.

  • WebSocket subscriptions per session

    Each active buyer subscribes to a topic shaped like 'matches near me, within these filters'. The server pushes match updates as soon as they happen; the client renders without polling. The subscription is bounded, leaving the page tears it down.

  • Queue-backed allocation, not request-time

    When supply is constrained, match allocation runs in BullMQ workers, not in the request handler. The buyer's request returns immediately with a pending match; the worker resolves the contention against inventory + business rules; the result lands over the WebSocket.

  • Tie-breaking that the operator can configure

    Two equally-valid matches: who wins? Configurable per marketplace, recency, rating, distance, price, surge multiplier. The rules live in the operator dashboard, not in the source code. Changing them doesn't require a deploy.

  • Match expiry + reallocation

    A match offered to a seller has a timeout. No accept inside the window → the engine reallocates to the next-ranked seller. The state machine is observable; operators can replay decisions during incidents.

  • Operator surfaces for the messy middle

    The operator dashboard shows live match queues, current matchmaker decisions, supply concentration, and the moments when buyers had to wait. The product team sees what to improve; the ops team sees what to intervene on.

Where this fits

  1. Your marketplace works for the seed cohort and breaks the first time supply and demand spike unevenly.

  2. You're matching today via polling + cron jobs and the latency is starting to show in retention.

  3. You're adding a geography dimension to a marketplace that previously matched on filters alone, and your current stack has no PostGIS.

Tech stack

  • TypeScript
  • Postgres
  • PostGIS
  • Elysia WebSockets
  • BullMQ

Want this for your team?

30 minutes with a founder or senior engineer. We'll scope what you need and tell you straight whether Stacklane fits.

Book a Free Call

Related capabilities

Other patterns in this area

Back to For Marketplaces