Case study 01 · Platform Architecture / Trading Infrastructure · 2025 – 2026
MetaTrader Plugin Management Platform
Independently architected and delivered a plugin management and licensing platform, connecting backend services, administrative interfaces, and customer-side runtime components.
- Domain
- Forex brokerage systems
- Role
- Architect & sole engineer
- Type
- Greenfield, concept to V1
- Stack
- .NET · React · MetaTrader
Challenge
Configuration and licensing for plugins running on customer-side infrastructure had to be managed centrally, with one engineer owning the whole system.
Key decision
A desired-state control plane: the backend records what each runtime should look like; runtimes report status and converge on it.
Result
Delivered from concept to a released V1: .NET services, React administration, runtime integration, licensing and automated tests.
From my work before founding ArtaPattern. Client names and confidential details are left out, and diagrams are conceptual.
A control plane for broker-side plugins
The platform manages MetaTrader server plugins for a brokerage: it holds their configuration and licences centrally, exposes an administration interface, and keeps the components running on the customer side in sync with what the backend says they should be.
Engineering context
The work sat inside a forex brokerage's engineering team, alongside C++ MetaTrader plugins and other broker-specific integrations. The platform was taken from concept to a first released version by one engineer, which made explicit structure and automated verification essential.
Problem & constraints
- Plugin configuration and licensing had to be managed from one place.
- Runtime components live on customer-side infrastructure, outside direct control of the backend.
- One engineer owned architecture, implementation and release, so the design had to stay small and verifiable.
Desired-state architecture
The backend acts as a control plane: it records the desired configuration and licence state for each runtime. Customer-side runtime components report their status and converge on that desired state, so configuration changes and licensing are centralized without the backend reaching into customer infrastructure.
Key engineering decisions
Separate the control plane from customer-side runtimes
Central configuration and licensing, with runtime components converging on a recorded desired state.
Model the domain before the services
Domain and data modeling came first so licensing, configuration and runtime status had clear owners.
Verify every release automatically
Automated tests and regression verification produced release evidence for each version.
Implementation & delivery
- 01
Model
Domain and data model.
- 02
Build
.NET services and React admin.
- 03
Integrate
Runtime and worker integration.
- 04
Release
Tests, evidence, V1.
OpenAI Codex supported discovery, planning, test-driven implementation, review and regression verification; changes were reviewed by an engineer before release.