cat ~/production/game-key-marketplace/REPORT.md

Game Key Marketplace

A three-sided digital marketplace: a supplier catalogue of tens of thousands of listings, kept in sync, priced in local currency, sold through a payment gateway with automated key delivery.

role Co-founder, Product and Engineeringtimeline 2025 - 2026category platform

Problem

Selling digital game keys in a market with its own currency and payment rails means solving three problems at once. A third-party supplier catalogue has to be continuously synchronised without duplicating or losing products. Prices arrive in one currency and have to be presented in another with an exchange rate you cannot control. And a purchase has to move money and deliver a key with no manual step in between.

Approach

Built the catalogue sync as a bounded worker pool over a shared page cursor rather than a naive parallel fetch, with connection reuse, exponential backoff with jitter, and retries limited to genuinely retryable failures. The sync cursor deliberately rewinds a short window on each pass, because clock skew between two systems will otherwise silently drop products updated in the gap. Catalogue gating runs thousands of lines of business rules with per-reason counters, so a supplier schema change that starts excluding everything is visible immediately rather than discovered by an empty storefront. Currency is resolved by request origin with a three-tier fallback, and money truncates rather than rounds at the payment boundary.

Outcome

Live, deployed, and taking real customers, with automated key delivery after payment. Co-founded the venture and owned the technical side end to end: architecture, integration, payment flow, deployment and operations.

180k+Catalogue · products including releases and gift cards
71Route handlers
8.5kApplication code · lines
LiveStatus · deployed, taking customers
architecture --explain

How it's built

Continuous supplier synchronisation feeding a gated local catalogue, priced per request origin, sold through a payment gateway with automated fulfilment. Workers are bounded and resumable, so a sync failure costs a retry rather than a full reimport.

Bounded worker pool over a shared cursor, not parallel fetch of all pages

A thousand pages fetched at once exhausts memory and gets rate limited. A bounded pool drawing from one cursor keeps concurrency and memory flat regardless of catalogue size.

More coordination code than a single parallel map, in exchange for a sync that finishes rather than falls over.

Cursor rewind on every sync pass

Two systems never agree exactly on the current time. Without rewinding a short window, any product updated between the previous cursor position and the actual query silently never syncs.

Some products are reprocessed each pass, which idempotent upserts absorb. That cost buys the guarantee that nothing is missed.

Per-reason exclusion counters on catalogue gating

Thousands of rules deciding what to list means a supplier field change can start silently excluding the entire catalogue. Counting exclusions by reason turns that into an observable number instead of a mystery.

Extra bookkeeping in the gating path, which is the cheapest observability in the system.

Truncate money, do not round, at the payment boundary

Rounding up can charge a customer more than the displayed price. Truncation is always in the customer favour and is defensible.

A fraction of a unit is absorbed per transaction, which is the correct side to err on.

related --by-stack

Adjacent systems

REL-001 / platform

Ceramics and Furniture Marketplace with AR

Multi-vendor marketplace where every supplier gets a storefront and the catalogue carries the material-specific attributes tiles and furniture actually need.

REL-002 / platform

Freelance Marketplace with Escrow

Two-sided marketplace for architecture and design work: the platform holds the money until delivery is confirmed, with bidding happening in real-time chat.

REL-003 / platform

Hardware Retail Platform with ERP Sync

Storefront, app and operations dashboard sitting in front of an external ERP, with data flowing both directions and staying consistent.