After 5 years of building and maintaining trading systems on the C-Trade platform in Zimbabwe and the NASD automated trading system in Nigeria, I've developed strong opinions about what makes a trading platform actually work in African markets — not just technically, but operationally and commercially.
This article isn't theoretical. It's grounded in real systems, real failures, and hard-won lessons from shipping production code that handles live financial transactions.
"The future of Africa's financial ecosystem will be built by engineers who understand both the software and the markets it serves."
The African Context: Why Standard Architecture Falls Short
Most trading platform architectures you'll find online are designed for mature markets: stable internet connections, high smartphone penetration, and well-established banking rails. Africa is different, and our architecture must reflect that.
The key constraints I design for:
- Intermittent connectivity — connections drop, and the system must handle graceful degradation
- Mobile-first users — the majority access via mobile data, not fibre broadband
- Multi-currency complexity — USD, ZWG, NGN, KES and cross-border settlement
- Regulatory variation — each country has its own securities regulator with different rules
- Low liquidity environments — order matching logic must handle thin books efficiently
The Core Architecture
Here's how I'd structure the system. I've broken it into five layers:
1. API Gateway & Authentication Layer
The entry point for all clients — mobile, web, and broker integrations. This layer handles:
- Rate limiting and DDoS protection
- JWT authentication with short-lived tokens and refresh rotation
- Request routing to downstream microservices
- API versioning to support multiple client versions simultaneously
// Example: JWT middleware in Node.js
const verifyToken = (req, res, next) => {
const token = req.headers['authorization']?.split(' ')[1];
if (!token) return res.status(401).json({ error: 'Unauthorised' });
jwt.verify(token, process.env.JWT_SECRET, (err, user) => {
if (err) return res.status(403).json({ error: 'Token expired' });
req.user = user;
next();
});
};2. Order Management System (OMS)
The heart of any trading platform. The OMS receives, validates, and routes orders to the matching engine. Key design decisions:
- Use a message queue (RabbitMQ or Redis Streams) between the API and matching engine to decouple concerns
- Implement idempotent order submission to prevent duplicate orders on retry
- Maintain full audit trails for regulatory compliance
- Design for eventual consistency — not every operation needs to be synchronous
3. Matching Engine
For African markets with thin order books, I'd implement a price-time priority matching algorithm. The matching engine should be:
- Single-threaded per trading symbol (avoids locking complexity)
- Written in a performant language — Python for prototyping, C# or Go for production
- In-memory order book with persistent event log for recovery
Don't over-engineer the matching engine for African markets. A clean, correct implementation beats a "high-frequency" one when liquidity is thin.
4. Market Data Distribution
Real-time market data is expensive to stream at scale. For African connectivity constraints, I use a hybrid approach:
- WebSockets for active trading sessions (desktop/good connectivity)
- Polling APIs as fallback for mobile users on 3G
- Compressed snapshots delivered at configurable intervals (1s, 5s, 30s)
- Delta compression — only send what changed, not the full order book
5. Settlement & Clearing
This is where most African exchanges struggle. Settlement must be:
- T+3 compatible (most African exchanges still run T+3 not T+1)
- Multi-currency aware with configurable FX rate feeds
- Integrated with local Central Securities Depositories (CSD)
- Built with fail-safe reconciliation processes that run nightly
Frontend Architecture: React + Next.js
For the trading dashboard, I'd use Next.js with the following optimisations:
- Server-Side Rendering (SSR) for the initial page load — critical for SEO and performance on slow connections
- React Query for server state management and intelligent caching
- Lazy loading of heavy chart components (TradingView widget loads only when needed)
- Progressive Web App (PWA) setup for offline access to portfolio data
What I Would Do Differently Today
Looking back at the systems I've built, here are the decisions I'd change:
- Start with observability — instrument everything from day one. We spent weeks debugging production issues that would have been obvious with proper logging and tracing.
- Design the data model for reporting first — regulators require specific reports. Design your schema around these requirements, not as an afterthought.
- Build mobile-first, not mobile-last — we retrofitted mobile support on a desktop-first codebase. It was painful. Start mobile-first.
- Invest in testing infrastructure early — financial systems need comprehensive test suites including property-based tests for the matching engine.
Conclusion
Building a trading platform for African markets is genuinely hard — but it's not as complex as Silicon Valley would have you believe. The fundamentals are well-understood. The challenge is adapting them to the African context: intermittent connectivity, thin liquidity, regulatory diversity, and mobile-first users.
If you're building in this space and want to discuss architecture, feel free to reach out. I'm always happy to talk systems with people building serious financial infrastructure.