A distributed browser-automation platform orchestrating ~2,500 sessions.
TKM is a distributed marketplace-automation platform that orchestrates around 2,500 managed accounts across three coordinated apps I built solo: a NestJS API that does the orchestration, a React web console for operators, and an Electron desktop application that drives a real anti-detect browser on each operator's machine. The three are tied together by one OpenAPI-typed contract, so a backend change that breaks a client fails at compile time. The hard engineering lives in the parts that have to survive at scale: per-account browser fingerprinting, sticky residential-proxy rotation with GeoIP, session warm-up and scheduling, and resilient status-sync pipelines on BullMQ.
Sole engineer on the whole platform: the NestJS orchestration API, the React web console and the Electron desktop application, plus the infrastructure and CI/CD under all of it.
The API publishes an OpenAPI contract consumed by both clients through openapi-fetch, so the wire is fully typed end to end. A backend change that breaks a client surfaces at compile time, not in production.
A clean NestJS module structure (accounts, proxies, orders, reviews, couriers, wallets, reports and more) over Prisma and PostgreSQL, with BullMQ and Redis for everything asynchronous.
Vitest integration tests against a real Postgres in Docker, with GitLab CI/CD and a Docker-based deploy.
Each account gets a deterministic, seeded browser fingerprint applied over CDP, with a realistic browser-version distribution and a five-day rotation plus a cooling-off window, so identities stay stable but never frozen.
Residential and mobile proxies resolved as sticky sessions and region-pinned with MaxMind GeoIP, enforcing one unique IP per account and tracking IP history so two accounts never share an address.
A narrow warm-up window prioritizes active accounts, and the desktop application detects logouts and re-authenticates before doing real work, instead of failing mid-task.
Bounded concurrency, retries and rate-limit control keep roughly 2,500 sessions running without tripping the anti-bot defenses they operate against.
Status sync runs as scheduled BullMQ jobs that process the fleet in capped batches on a cron, so load stays smooth instead of spiking.
The desktop application intercepts marketplace calls over CDP and streams hints to the API, which normalizes them into a clean order, position and pickup-point model.
A FIFO matching algorithm reconciles later events back to the right order using the most reliable real-world signal, keeping the data consistent even when events arrive out of order.
Operation success is scored with Wilson confidence intervals rather than raw ratios, so small samples don't produce misleading numbers.
A cross-platform Electron app with auto-update and CI-built, signed Windows releases published to S3, sharing its React codebase with the web console.
Account and job status is pushed live to both clients over Socket.IO, so operators see state change without refreshing.
Prometheus metrics and rotating Winston logs for visibility, plus a Telegram bot for operational broadcasts and excel and PDF report generation.
Built for Marketplace operations, E-commerce automation.
Manage ~2,500 marketplace accounts, each with its own identity, proxy and schedule, from one console.
An Electron app drives a real Chrome per account with a deterministic, rotating browser fingerprint.
Sticky residential and mobile proxies, GeoIP region pinning, and one unique IP per account, tracked over time.
Session warm-up windows and a scheduler that paces work across accounts to stay under rate limits.
Background BullMQ workers reconcile order and review state into a single normalized data model.
A React dashboard with thousand-row tables, filters and live status pushed over Socket.IO.
There are no screenshots here on purpose — this is a private NDA project and nothing real is shown. So here is the engineering instead: what happens from the moment the desktop application asks for a session to the data landing clean in Postgres.
The desktop application asks the API for a session: identity, sticky proxy and a region-pinned IP, under an open-lock so two instances never collide.
It launches a real Chrome with the account's deterministic fingerprint over CDP, restores state and warms the proxy before any real work.
Work happens in a real browser; the desktop application intercepts the relevant calls over CDP and streams structured hints back to the API.
The API normalizes those hints into a clean order, position and pickup-point model in PostgreSQL through Prisma.
Scheduled BullMQ workers reconcile later state back to the right record with a FIFO matching pass, keeping the data consistent.
Deterministic per-account seed over CDP, realistic version split, 5-day rotation + cooling-off.
Sticky residential & mobile sessions, one unique IP per account, IP history tracked.
MaxMind region pinning so an account's IP stays geographically consistent.
A narrow warm-up window prioritizes active accounts before real operations.
Logout detection and re-auth before work, instead of failing mid-task.
Bounded concurrency, retries and rate-limit control across ~2,500 sessions.
Private commercial project under NDA. No real accounts, customer data, credentials or screenshots are shown; the system is described in the abstract and visualized as architecture only. A deeper walkthrough is available on request.