Skip to content

Last Updated: 2026-05-03 Owner: Docs-Dev Summary: Prompt for generating a full component-by-component system design document for QuantMatrix.

QuantMatrix System Design Prompt

You are a principal systems architect and staff engineer.

I am building a production-grade automated momentum day trading system called QuantMatrix.

Your job is to help me create a complete, implementation-ready system design document, component by component, in a way that is easy for an engineer to understand and build step by step without missing anything.

I want the design to be: - robust - modular - production-oriented - easy to extend - broker-agnostic where possible - suitable for both live trading and backtesting - explicit about failure handling, interfaces, dependencies, and operational concerns

System context: - The platform is an automated momentum day trading system - It has a UI, market-data ingestion, momentum radar, scanner engine, active strategy watchlist, strategy allocator, buy/sell strategy engine, order execution service, global risk manager, account summary, positions, orders, P&L, health monitoring, settings, and backtesting/data download flows - We may use different brokers for market data and execution - We may use Redis for cache/event/state and PostgreSQL for durable records - The system should support paper trading, live trading, and backtesting modes - The system must be easy to implement module by module - The system must store rich trade context and post-trade analytics so we can analyze why each trade made or lost money and generate recommendations for improving future trades

I do NOT want a vague high-level overview. I want a full engineering design package.

Please produce the output in the exact structure below.

  1. Executive Summary
  2. Describe the system in plain English
  3. State key design goals
  4. State non-goals

  5. State architectural principles

  6. Full Component Inventory For each component, provide:

  7. Name
  8. Purpose
  9. Responsibilities
  10. Inputs
  11. Outputs
  12. Internal state
  13. Dependencies
  14. Failure modes
  15. Scaling concerns
  16. Why this component should exist separately

Components to cover at minimum: - UI frontend - API/backend gateway - Account summary service - Momentum Radar service - Momentum snapshot store - Opportunity Scanner Engine - Active Strategy Watchlist manager - Strategy Allocator - Entry Signal Generator - Exit Signal Generator - Order Execution Service - Broker abstraction layer - Market Data abstraction layer - Global Risk Manager - Positions service - Orders service - P&L service - Trade journal and analytics service - Recommendation and insights service - Health monitoring service - Historical data download service - Backtesting engine - Settings/configuration service - Audit/logging service - Notification/alert service - Scheduler/time-sync service

  1. Technology Recommendation Per Component For each component, recommend:
  2. Best language/runtime
  3. Best framework/library
  4. Best storage choice
  5. Best communication method
  6. Best deployment shape
  7. Why this technology is the best fit
  8. Alternatives and tradeoffs
  9. Whether the component should be synchronous, asynchronous, scheduled, or event-driven

Be explicit. Do not just say "use Python" everywhere unless justified.

  1. Data Flow Design Describe end-to-end flows in detail:
  2. market data -> radar -> snapshot store -> scanner -> watchlist
  3. watchlist -> strategy allocator -> buy strategy -> order execution
  4. filled order -> sell strategy -> exit -> closed trade
  5. closed trade -> trade journal -> analytics -> recommendation generation
  6. broker account -> account summary -> UI
  7. historical data download -> backtesting engine
  8. settings changes -> runtime behavior
  9. risk rule breach -> halt/override flow
  10. emergency liquidate flow

For each flow include: - triggering event - sequence of components - state changes - persistence points - retries - idempotency requirements - monitoring points

  1. Interface Contracts For each component define:
  2. API endpoints or function signatures
  3. request and response schema
  4. event schema
  5. Redis key design if relevant
  6. database schema if relevant
  7. ownership boundaries
  8. validation rules

For trade analytics specifically, define how to capture and expose: - strategy used - entry setup conditions - exit trigger conditions - key technical indicators at entry and exit - slippage and execution quality - hold duration - realized P&L and MFE/MAE - market regime or session context - free-form notes or machine-generated explanations - recommendation outputs for future strategy tuning

Make this precise enough that multiple engineers could implement independently.

  1. Storage Design Recommend what should live in:
  2. Redis
  3. PostgreSQL
  4. in-memory only
  5. object/file storage if needed

For each entity explain: - why it belongs there - retention policy - indexing/query pattern - consistency requirement - whether it is source of truth or cache

Be explicit about storage for: - raw trade events - normalized completed trades - per-trade feature vectors - trade outcome labels - derived analytics summaries - recommendation history

  1. Reliability and Failure Handling For each component explain:
  2. what can fail
  3. how failure is detected
  4. retry strategy
  5. timeout strategy
  6. fallback behavior
  7. alerting behavior
  8. what should be persisted before recovery

  9. what must be idempotent

  10. Security and Compliance Considerations Cover:

  11. secrets handling
  12. broker API key management
  13. audit trails
  14. access control
  15. operational safety
  16. accidental trade prevention
  17. environment separation between dev, paper, and live

  18. privacy and governance for trade analytics, including how recommendation logic is versioned and auditable

  19. Step-by-Step Build Plan Break implementation into phases. For each phase include:

  20. goal
  21. components to build
  22. dependencies
  23. acceptance criteria
  24. risks
  25. what should be mocked first
  26. what should be productionized later

The plan should let me build the system cleanly without skipping hidden prerequisites.

  1. Test Strategy For each component define:
  2. unit tests
  3. integration tests
  4. simulation tests
  5. failure tests
  6. end-to-end tests
  7. backtesting validation
  8. paper trading validation
  9. production-readiness checks

  10. analytics correctness validation, including whether trade explanations and recommendations are reproducible from stored trade data

  11. Open Decisions and Tradeoffs List unresolved architecture decisions and give 2-3 options with pros/cons.

  12. Final Deliverables At the end, produce:

  13. a system module map
  14. implementation order
  15. dependency graph
  16. minimum viable version
  17. production-ready version
  18. recommended first milestone
  19. a dedicated trade analytics architecture showing how the system learns from previous trades and turns that into actionable recommendations

Important rules: - Be concrete, not generic - Be explicit about component boundaries - Avoid hand-wavy descriptions - Prefer modular architecture over monolith unless justified - Prefer designs that are easy to build incrementally - Assume a small engineering team that wants maintainability - If a component should be split further, say so - If a component should not exist yet, say so - If one technology is risky, call it out clearly - Include tables where useful - Include diagrams in Mermaid when useful

Recommended usage: 1. Pass 1: architecture only 2. Pass 2: interfaces, schemas, Redis keys, DB contracts 3. Pass 3: build plan, testing, operations, dependency order