Marketplace Matching Engine
A distributed request-to-match state machine across WordPress, CRM and two automation layers
Context
A matching platform connects clients who submit a request with vetted professionals who unlock it for credits. Between those two moments sits a lifecycle nothing off-the-shelf provides: the request must reach the right professionals by specialty and region, one at a time, each offer expiring on a clock; unanswered requests must escalate through a supervisor to a pool broadcast; and when the whole pool is notified at once, exactly one professional can win the unlock, a concurrency guarantee, not a hope.
The engagement is the ongoing engineering of that machine as a distributed state machine across four systems: WordPress with a custom post type and ACF field contract as the system of record, FluentCRM for audience resolution and messaging, and n8n plus Make.com as the orchestration layers, REST as the contract between them, MySQL advisory locks where correctness cannot be negotiated, and watchdogs everywhere state could silently rot.
The Challenge
- Distributed state: four systems each hold part of the request lifecycle, and they must never disagree about what state a request is in.
- The first-accept problem: a 24-hour pool broadcast means dozens of professionals can try to unlock the same request in the same second, double-selling is a business catastrophe, so mutual exclusion had to be absolute.
- PII discipline: professionals must see enough to decide (region, specialty) and nothing more until they pay the unlock, data minimization as an architectural requirement.
- Timers everywhere: hours-scale offer TTLs, a 24-hour pool window and expiry semantics, all enforced by machinery, with business-hours awareness, because nobody is watching a clock.
- Stateful content behind page caching: request dashboards must reflect true state instantly while the rest of the site stays cached.
Scope and Approach
-
01
Intake and identity
A form submission becomes a draft custom post under an ACF field contract plus a CRM contact, confirmed through a pre-filled double-opt-in form before anything dispatches. Intake is rate-limited and regionally scoped, and account provisioning lands in a dedicated least-privilege role.
-
02
Dispatch engine
A cross-system round-robin resolves eligible CRM candidates by specialty and region tags, selects the least-loaded professional using a load counter with a deterministic seniority tie-break, stamps the offer with an expiry timestamp, and notifies, repeating for up to three exclusive rounds, each excluding prior decliners.
-
03
Escalation and supervisor queue
Requests that exhaust three rounds transition to a pending state and surface in a supervisor operations dashboard with nonce-guarded, capability-checked status actions, a human decision point in the middle of an automated pipeline, with the queue as filterable data rather than an inbox.
-
04
Pool broadcast with first-accept locking
Validated requests broadcast to the entire eligible pool on a 24-hour window. First acceptance wins under a MySQL advisory lock acquired at unlock time, mutual exclusion enforced at the database layer, so simultaneous unlock attempts resolve to exactly one winner and everyone else gets a clean "already taken".
-
05
Security and privacy layer
REST API hardened with anti-leak response filtering and application-password guardrails; dashboards render masked request summaries until unlock; every notification is PII-minimized, region and specialty only, no client identity in any email.
-
06
Reliability and observability
A 15-minute reconciliation watcher advances every active request, applying exclusion predicates, expiring stale offers, honoring business-hours fallback. A cache-hygiene layer keeps stateful views correct behind page caching, and memory plus audit-state watchdogs catch anomalies before users do.
-
07
Versioned delivery
The platform logic ships as ~30 versioned, self-contained production snippets, each with a documented purpose and data flow, every prior version retained, the audit trail is the deployment history.
Architecture flow
Technical Deep Dive
The advisory-lock unlock
Application-level checks ("is it still available?") cannot survive concurrent requests, two professionals can both pass the check before either writes. The unlock path acquires a named MySQL advisory lock, re-reads state under the lock, commits the acceptance and releases, check-then-act collapsed into a critical section. The race condition is not rare-and-handled; it is structurally impossible.
Least-loaded selection with deterministic tie-breaks
Fair dispatch is a business requirement: professionals pay to participate. Selection orders candidates by an offer counter maintained on the professional record, breaking ties by seniority, fully deterministic, so any dispatch decision can be explained after the fact from data that still exists.
The 15-minute reconciliation sweep
Event-driven systems drift: a webhook is missed, a service hiccups, and a request stalls in a state forever. The watcher is the corrective loop, every 15 minutes it re-derives what should happen next for every active request (advance round, expire offer, escalate to pool) with exclusion filters and business-hours fallback, making the whole machine self-healing rather than fragile.
Cache hygiene for stateful CPT views
Request state changes minute to minute; page caching wants to freeze everything. The cache-hygiene layer targets exactly the views that render request state, invalidating them on state transitions while the rest of the site keeps its full-cache speed, correctness and performance instead of one or the other.
PII minimization as an offer-email property
Offer and pool notifications carry region and specialty only. The client's identity and request details exist in exactly one place until unlock, the system of record, which shrinks the breach surface, keeps professionals honest about paying for access, and aligns the platform with data-minimization principles by construction.
Engineering Decisions
WordPress CPT as the system of record
The request lifecycle lives in one place, a custom post type with an ACF field contract, and every other system reads and writes through REST against it. Distributing the source of truth across the CRM and automation layers would have made every bug a forensic investigation.
Database-layer locking over application flags
An "is_locked" meta flag fails under concurrency in exactly the scenario that matters (the whole pool clicking at once). MySQL advisory locks cost one function call and provide a guarantee the application layer cannot, the cheap version of correctness was chosen over the plausible version.
Snippets with retained versions over a monolith
Roughly 30 self-contained, versioned units, each deployable and rollback-able alone. On a live platform where dispatch runs daily, small reversible changes beat release-cycle risk, and the version history doubles as the audit trail.
A human gate before the pool
Escalation to all-pros broadcast is deliberately supervised, a supervisor validates before the platform notifies everyone. Full automation was possible; the checkpoint exists because a mis-dispatched broadcast is expensive in trust, and the queue design makes the human step take seconds.
Results
- A distributed request-to-match state machine, intake, dispatch, escalation, pool, expiry, running unattended across four systems.
- Race-condition-proof acceptance: database-layer mutual exclusion guarantees one winner when the whole pool responds at once.
- Data minimization as architecture: professionals see region and specialty only until they unlock.
- TTL and SLA semantics enforced by a self-healing 15-minute reconciliation watcher with business-hours fallback.
- Stateful request views stay correct behind full-page caching, correctness and performance together.
- ~30 versioned production snippets shipped, with watchdogs and audit state guarding the platform.
Have a system that needs
this kind of work?
Tell me what is breaking or what you need built. I will reply with how I would approach it and what I would check first.