CASE STUDY / 02 · Risk & supervision
A separate monitoring application with the ability to alert, cancel orders, command strategy shutdown and close positions — outside the strategy application itself.
01 / Context
The strategy application included its own automated emergency logic. I also built a separate RabbitMQ-based supervisor to observe accounts and orders and intervene when needed, including when the strategy application encountered a problem. This introduced a second application-level route for monitoring and action.
02 / Engineering decisions
Placed monitoring and intervention in a separate application from strategy execution. This gave the supervisory logic its own application-level responsibility and a route to issue actions when a strategy application encountered a problem.
Implemented account/order observation and alerts alongside the ability to cancel outstanding orders, send a stop command to the strategy application and close positions. The supervisor could act as well as report.
The conceptual model separates requesting a stop, cancellation or close from a resulting confirmed state. The interactive example uses synthetic confirmations to explain that distinction; it does not expose or reproduce the employer message protocol.
The independent supervisor complemented the automated emergency logic already implemented in the strategy application. Both are part of the confirmed scope of the work.
03 / System responsibilities
High-level model of responsibilities. Internal implementation details are omitted.
A second application provides a separate place for supervisory logic. Whether it survives a particular outage depends on shared processes, network, broker state and infrastructure; those details are outside this public case study.
04 / Validation & outcomes
Account/order monitoring, alerts, order cancellation, strategy-stop commands and position closing.
RabbitMQ connected the supervisory workflow. Internal exchanges, queues, message contracts and deployment details are omitted.
The portfolio describes implemented capabilities. It does not claim formal fault-injection coverage, guaranteed intervention or a recovery-time target.
The view is deliberately abstract: no internal queue names, message schemas, thresholds, infrastructure or employer source code.
Diagrams and interactive examples are explanatory models. Employer code, account data and strategy logic remain confidential.
LET’S CONNECT
For engineering conversations and opportunities across trading platforms, financial backend systems and payments.
pouriajamali91@gmail.com Connect on LinkedInRÉSUMÉS / CONTACT