TFLMarkets

Overview

TFLMarkets lets traders take simulated prop-firm challenges and enter trading tournaments on live market prices. Orders never reach a real market, but the fees, the wallet, payouts and identity checks involve real money and real people. It runs in production.

Between April and September 2026 I designed the platform and built it with one other engineer. Of about 2,200 backend commits, about 1,600 are mine, and about 70% of the frontend commits. Most of the code was written by AI coding agents from specifications I wrote; I reviewed, tested, integrated and deployed it. Five services were brought in from earlier company code and extended.

Architecture

Twenty Go services, a Rust trading engine, a C# bridge to the price source, a Python service for identity-document checks and a small TypeScript history source. Most service-to-service calls are REST; the hot paths (prices into the engine, orders from the gateway) are gRPC. Every service owns its own PostgreSQL database behind PgBouncer.

Event backbone

Domain events (account created, order filled, breach detected and so on) travel through Kafka, encoded with Avro against 180 schemas in a Schema Registry. Each service writes its events to an outbox table in the same transaction as its own state change, and a publisher sends them on, so a crash can never leave a change without its event. Order placement is idempotent on a client order id, and consumers that cannot process a message send it to a per-topic dead-letter queue.

Live prices take a different path. The price-feed service streams ticks to the Rust engine over gRPC and publishes them on Redis Pub/Sub, where the WebSocket gateway I wrote picks them up and sends them to each client, throttled per connection. Market data is stored in QuestDB for ticks and TimescaleDB hypertables for candles.

Web applications and the WebGL chart

Five Nuxt applications share a monorepo with common design tokens, UI components and an API client: the trading terminal, the user dashboard (wallet, KYC), the admin back office, the marketing site and a bilingual blog.

The terminal's chart is built in-house, with no charting library: series, axes, crosshair and about 70 drawing tools. I wrote its WebGL2 series renderer:

• All coordinate maths runs in 64-bit floats in JavaScript and only pixel positions are sent to the GPU, because FX prices lose precision in 32-bit floats.
• Candles are drawn as quads grouped by colour: four draw calls by default, however many candles are on screen, from one reused vertex buffer.
• It shares its pixel maths with the Canvas 2D renderer, so the two produce the same pixels. If WebGL is unavailable, a shader fails or the context is lost for more than two seconds, the chart switches to Canvas 2D.

Screenshots

The trading terminal and its WebGL chart

Images of the real product; the note below says where and how they were captured.

Production operations

Production runs on Docker Swarm, deployed by GitLab CI from a runner on the host: each service is rolled forward and checked for health. I set up the monitoring stack (Prometheus with about 520 alert rules including SLO burn-rate alerts, 36 generated Grafana dashboards, Loki for logs, Tempo and OpenTelemetry for traces, and Alertmanager) and wrote the runbooks: more than 60 operational runbooks and about 130 more for individual alerts.

Backups came late. From August 2026 the databases have encrypted offsite backups and point-in-time recovery with pgBackRest.

Incident review

In August 2026 three small symptoms were reported together: lock warnings in the PostgreSQL log, connection resets, and a dozen events that failed to publish. Nothing looked broken and no alert had fired. I investigated read-only against production first, and found three separate causes and a fourth, more serious problem nobody had reported.

1. Advisory locks behind a transaction pooler. Outbox publishers elected a leader with PostgreSQL session advisory locks. Behind PgBouncer in transaction mode, the lock stays on a backend the application no longer controls, so leadership could be held by two replicas or by none. Production showed zero advisory locks held while four services believed they had one.
2. Connection resets. Two were explained by a redeploy; 23 could not be attributed with the logging in place, and I reported them as unattributable instead of guessing.
3. Transient Kafka outages. The single broker had fenced itself three times. All twelve affected events were shown to have been delivered and handled, from four independent facts.
4. Unbounded retries. Events that could never succeed (a schema mismatch, a missing topic) were retried without limit and blocked the head of their queue. One row had over 5 million attempts. Eighteen risk events had been stuck for 49 days, because the only signal was a counter that fired once.

What I changed. A shared retry library that classifies failures (transient, permanent, ambiguous, missing topic), backs off and parks permanent failures for review, live on 11 of 13 event publishers; the two money services were held for a second review. A pooler-safe lock and a Redis lease elector, adopted by the first service when my work ended. Alert rules for work that is over budget, and a repair tool for the stuck events that reconciles them instead of replaying them.

Lessons. "Healthy" is not "working"; a counter is not a backlog; a retry column that nothing reads is not a limit; and pooling mode is part of your concurrency model.

Load test

How the work was done

The design lives in 30 architecture specifications. Coding agents implemented from them, and I reviewed, tested and integrated the result. About two thirds of the commits carry an AI co-author tag. The repository has about 6,800 Go test functions, about 1,100 Rust tests and integration tests against real PostgreSQL with Testcontainers, run locally rather than in the deployment pipeline. My public example of the same way of working, with tests you can inspect, is BoundedCode.

My role

• Co-founder and technical lead; designed the architecture and wrote the specifications.
• Wrote most of the backend, including the WebSocket gateway and nearly all of the infrastructure, CI and monitoring; the other engineer wrote more of the prop and tournament services than I did.
• Built most of the five frontends, including the WebGL renderer.
• Ran production: deployments, incidents, backups.

Limitations

• Everything here is self-reported; the code and raw data are private.
• Production ran on a single node, and backups arrived in August 2026.
• The load test is one run from one machine, and it missed two of its own targets.
• The incident fixes were still being rolled out when my work ended.