AlphaSync · Technical architecture
AlphaSync Architecture
From market data to strategy execution, AlphaSync is structured as a modular trading technology platform with dedicated layers for data, intelligence, risk, execution and analytics.
01 · System overview
One pipeline, with the risk engine in the path.
Data enters at the top and results leave at the bottom. Every stage is a separate component with a defined interface, and all of them share the same platform services.
Figure 1 · AlphaSync system architecture
- Market dataLive NSE and BSE prices from broker market-data interfaces
- Data processingValidated and normalised into one internal format
- Strategy engineOne strategy definition for backtest, paper and live
- Risk engineEvery intended order is checked here. No other path to a broker
- Order managementOrder creation, validation and status tracking
- Execution & broker connectivityOne adapter per broker, official APIs, the user’s own account
- Positions & portfolioPositions and P&L across accounts
- Analytics & reportingEvery signal, order and fill recorded and reported
02 · Platform layers
Seven layers, each with one job.
Separating the platform into layers keeps each concern in one place. A change to how a broker responds, for example, is contained in the execution layer and does not reach strategy code.
- React
- TypeScript
- Android monitor app
- FastAPI
- Python
- Strategy builder
- Indicators
- Python strategies
- Backtesting
- Paper trading
- Signal generation
- Stop-loss
- Position sizing
- Daily loss limit
- Margin cap
- Order-rate limits
- Kill switch
- Order management
- Broker adapters
- Position tracking
- Market data
- Orders & fills
- Strategies
- Users & accounts
- Analytics
- MySQL
- Logging
- Monitoring
- Access control
03 · Market data flow
Data quality comes first.
A trading system can only be as sound as the data it acts on. Inconsistent prices or timestamps become wrong decisions, so data is normalised early and treated as a first-class part of the architecture. When data is lost, the platform stops acting on it and tells the user.
Figure 2 · Market data flow
- Market data sourceLive NSE and BSE prices arrive through broker market-data interfaces: streaming where the broker offers it, polling where it offers only request-based access.
- IngestionEach broker’s feed is received by its own adapter, so no downstream component depends on one broker’s format.
- ValidationIncoming data is designed to be checked for gaps, staleness and ordering before anything acts on it.
- NormalisationData is converted into one internal format, so every component sees the same instrument, the same timestamp and the same price.
- ProcessingIndicators and derived values are calculated from the normalised stream.
- Strategy consumptionStrategies evaluate the same data in the same way in backtesting, paper trading and live.
- Risk evaluationAny order a strategy intends is checked against the user’s limits.
- Execution decisionOnly approved orders proceed to order management and the broker.
- AnalyticsSignals, orders and fills are recorded, which feeds reporting and the audit trail.
04 · Strategy engine
Define once. Test, validate and run the same definition.
The core design decision in AlphaSync is continuity: the strategy that is backtested is exactly the strategy that is paper traded and then traded live. There is no rewrite between stages, so validation applies to what actually trades.
A strategy only reaches live capital after it has been tested on history and validated on live prices.
- Indicator-based rulesEntry and exit conditions from indicators such as RSI, MACD, Bollinger Bands and EMA, plus price action and time filters.
- Visual strategy builderRules assembled without code.
- Python for custom logicStrategies written in Python run through the same backtest, paper and live pipeline.
- Signal generationStrategies emit signals; they never place orders themselves.
- BacktestingHistorical NSE and BSE data, with reports on CAGR, Sharpe ratio, maximum drawdown, win rate and trade-by-trade P&L.
- Parameters and variantsParameters are configurable, and variants are compared side by side.
- Paper tradingLive prices, simulated orders, no capital at risk.
05 · Risk engine
In the path, not beside it.
No component can place an order without passing the risk engine. That is what makes limits enforceable rather than advisory. Limits are set by the user and enforced by AlphaSync between strategy and execution.
Figure 3 · Order validation by the risk engine
- 01Strategy signalAn intended order
- 02Risk engineChecks every limit
- 03ApprovedContinues to order management
- 04RejectedStopped and recorded
| Scope | Control |
|---|---|
| Per trade | Stop-loss · position sizing |
| Per day | Maximum-loss limit |
| Per account | Margin utilisation cap |
| Order flow | Order-rate limits |
| Emergency | Kill switch that halts all live orders |
| Record | Signals, orders and fills logged for review |
06 · Order management & execution
An order is a lifecycle, not a message.
Once an order leaves the platform, its true state is held by the broker. The design rule is never to assume a state that has not been confirmed.
Figure 4 · Order lifecycle
- Strategy signalThe strategy expresses an intended trade.
- Risk validationThe risk engine applies the user’s limits. Rejected orders stop here.
- Order creationAn approved order is created, and its state is tracked from this point on.
- Order validationThe order is shaped to the broker’s rules for order types and sessions by that broker’s adapter.
- Broker APIThe order is sent through the broker’s official API to the user’s own account.
- Order statusAcknowledgements, rejections and updates from the broker are tracked.
- Execution confirmationFills are recorded as the broker reports them.
- Position updatePositions and P&L are designed to update from confirmed executions.
- Status managementEach order’s state is tracked from creation to final status.
- Error handlingWhen a connection or response is lost, the platform stops acting and reports to the user rather than guessing.
- Retry where applicableAny resubmission is designed to follow a confirmed order status, never a timeout alone.
- ReconciliationPositions are designed to be checked against broker-reported state.
- Execution audit trailSignals, orders and fills are recorded for review.
07 · Broker connectivity
Every broker behind its own adapter.
Brokers differ in order types, sessions, responses and how they deliver market data. Isolating each one behind a controlled integration layer keeps those differences in one place, and lets new brokers be added without changing strategies.
Figure 5 · Broker connectivity
- 01AlphaSyncStrategy, risk and order management
- 02Broker connectivity layerOne adapter per broker
- 03Broker APIOfficial broker interface
- 04ExchangeNSE · BSE, via the broker
Connected brokers
- Zerodha
- Alice Blue
- IIFL
- Zebu
- BNR
Connections go to the user’s own broker account. Funds stay with the broker.
- AuthenticationEach broker connection is authorised by the account holder.
- API credentialsHeld server-side, never in front-end code.
- Request validationOrders are shaped to each broker’s rules before they are sent.
- Order routingApproved orders go to the right account through the right adapter.
- Order statusBroker responses and updates are tracked per order.
- Position synchronisationPositions are designed to follow broker-reported state.
- Failure handlingA lost connection stops trading activity and alerts the user.
- Multiple accountsSeveral accounts can be managed from one interface.
08 · Security architecture
Security surrounds every layer.
Security in AlphaSync is not a component in the pipeline. It is a set of controls that apply to every layer, from the interface to the data. How we approach technology and security.
Figure 6 · Security as a cross-cutting concern
- PresentationReact web interface and Android monitor app
- API layerFastAPI services: the only entry point
- Domain servicesStrategy, risk, orders, portfolio, analytics, administration
- Risk & executionThe enforcement point and broker adapters
- DataMySQL system of record
09 · Database architecture
Relational, by default.
MySQL is the system of record. A relational model keeps orders, fills, positions and the audit trail consistent with each other, which matters more in trading than raw write speed.
Figure 7 · Logical data domains
Identity & access
- Users
- Accounts
- Permissions
Trading
- Orders
- Trades & fills
- Positions
Strategy & risk
- Strategies
- Backtest results
- Risk parameters
Records
- Configurations
- Audit events
- Reports
10 · Real-time communication
Pushed, not polled.
The browser keeps an open WebSocket connection, so the interface can update as events happen instead of repeatedly asking the server. Where a broker offers only request-based data, the platform polls that broker and passes updates on through the same channel.
Figure 8 · Real-time path to the browser
- 01Backend servicesMarket data, orders, positions, alerts
- 02WebSocket layerPersistent connection to each client
- 03React clientUpdates the interface as events arrive
- Market prices
- Order status
- Positions
- P&L
- Alerts
- System events
11 · Observability
Visible while it runs, explainable afterwards.
Every service emits logs and metrics and reports its health. Monitoring turns these into a picture of the running platform, and alerts reach the people who need to act. Users receive their own alerts for prices, triggers and fills.
Figure 9 · Observability pipeline
- 01Services
- 02Logs
- 03Metrics
- 04Health checks
- 05Monitoring
- 06AlertsIn-app · email · Telegram
- 07Operations
Incident detection
Problems are seen as they start.
Debugging
Logs show the sequence of events.
Performance analysis
Measured, not guessed.
Operational visibility
One view of platform state.
Auditability
A record of what happened, and why.
12 · Deployment architecture
From reviewed code to a monitored service.
A high-level view of how a change reaches production. Tools, hosting and infrastructure details vary by deployment and are not published.
Figure 10 · Deployment path
- DeveloperChanges are made with typed interfaces and automated tests.
- Source repositoryEvery change is code-reviewed before it is merged.
- Build & testAutomated tests run on each change.
- Container imagesServices are packaged as container images where applicable, so every environment runs the same build.
- Deployment environmentSeparate from development and testing, with its own configuration and credentials.
- Application servicesAPI, domain services and broker adapters.
- Database & supporting servicesMySQL and any services the deployment requires.
- MonitoringHealth, logs and alerts from the moment services start.
13 · Resilience & failure handling
When in doubt, stop and report.
Failures are designed to be safe. The platform does not guess when data or a connection is lost; it stops acting and tells the user. The kill switch halts all live orders at once. No system can promise zero downtime, and this one does not.
| Failure | Detection | Response | Outcome |
|---|---|---|---|
| Market data failure | Missing or stale data | Strategies stop acting on the affected data; the user is alerted | Safe state: no orders placed on bad data |
| Broker API failure | Rejected, failed or unanswered request | Stop and report; any recovery follows the confirmed order status | Order and position state reconciled with the broker |
| Database failure | Failed writes or health check | Recovery according to the deployment’s documented procedure | Service restored to a consistent state |
| Service failure | Health check | Restart or recovery where configured | Service back in operation, with the event logged |
| Network failure | Lost connection | Stop, report, then a controlled reconnection | Trading resumes only on confirmed state |
14 · Data & event flow
From the user to the data, and back.
The full request path in one view. Each tier is designed to talk only to the tier next to it, which keeps responsibilities separate and failures contained.
Figure 11 · Data and event flow
User
Client
API
Domain services
Data & integration
Observability
15 · Technical design principles
Ten rules the architecture follows.
Modular architecture
Components with defined interfaces, replaceable one at a time.
Separation of concerns
Strategy, risk, execution and data each live in one place.
Security by design
Controls are part of the architecture, not added later.
Least-privilege access
Every user and service gets only what its job needs.
Observable services
Every service reports its logs, metrics and health.
Controlled execution
No order reaches a broker without passing the risk engine.
Data integrity
One normalised format and one relational system of record.
Failure isolation
A fault in one broker adapter or service is contained there.
Auditability
Signals, orders and fills are recorded for review.
Extensibility
New brokers and strategies are added without changing the rest.
Architecture note. Architecture and deployment configurations may vary according to product version, customer requirements, broker integrations, infrastructure configuration and operating environment. The diagrams show the logical architecture; not every deployment uses every component shown. AlphaSync is trading technology, not investment advice. Vianmax™ is not a SEBI-registered investment adviser, research analyst or stock broker.
Explore the platform.
See AlphaSync with your own strategies, or ask the engineering team a technical question.