Architecture

System Architecture Overview

Main flow

Error path

Camel Route

Stage 1

Tick Files

CSV market data
from disk

data/input/

*.csv

          
Stage 2
Ingestion Route
Polling Consumer
Msg Filter
Translator
CSV→TickEvent

          
          
            
          
        
Stage 3
Statistics Engine
Splitter fans out
to 5 stat topics
stat.avg
stat.mavg
stat.stddev
stat.min
stat.max

          
Stage 4
Trading Engines
Selective Consumer
+ Aggregator
🗽 NYC — New York
🇬🇧 LON — London
🗼 TYO — Tokyo
Corr. ID / setHeader

Stage 5

ReportingService

Formats & records
all decisions

Singleton

Thread-safe

Dead Letter

queue.invalid.ticks

Invalid / malformed
tick messages

This slide shows the end-to-end architecture. I will walk through it from left to right. The input is a set of CSV tick files under the data input directory. Apache Camel polls those files, reads each row, and sends the row into the ingestion route. The ingestion route parses the CSV text into a TickEvent object and validates it. If a row is malformed or has invalid market data, it does not disappear silently. It is sent to the invalid tick queue so the failure stays visible. If the tick is valid, it moves into the main market tick topic. From there, the statistics engine receives the tick and fans it out into five calculations: average, moving average, standard deviation, minimum, and maximum. Each statistic is published to its own topic. That separation is important because it allows each trading engine to consume only the signals it needs. New York, London, and Tokyo subscribe to different combinations of symbols and statistic types. Each engine aggregates related statistic events into a SignalSnapshot, applies its trading strategy, updates its position state, and sends the result to the ReportingService. The key idea is that Camel and ActiveMQ handle message movement, while the object model handles the domain behavior.