Skip to content

Latest commit

 

History

History
40 lines (32 loc) · 1.96 KB

File metadata and controls

40 lines (32 loc) · 1.96 KB

Architecture Overview

QuantDinger v5 separates HTTP request handling, long-running trading, scheduling, finite background jobs, and database migration into explicit process roles. PostgreSQL coordinates durable ownership; the two Redis tiers serve different reliability requirements.

Runtime ownership

Surface Owns Must not own
backend Authentication, validation, queries, durable command submission Trading loops and long-running schedules
trading-worker Strategy runtimes, broker sessions, orders, leases, reconciliation Public HTTP request handling
scheduler-worker Portfolio, deployment, payment, and notification schedules General Celery work
celery-worker Finite, serializable, retryable jobs Persistent trading runtimes
migration Ordered schema updates Concurrent API serving

State and coordination

  • PostgreSQL is the source of truth for commands, leases, heartbeats, audit records, strategies, and trading state.
  • redis is an evictable cache and must not hold durable queue state.
  • redis-jobs is the Celery broker/result tier, uses AOF and noeviction, and must be monitored for memory pressure.
  • Idempotency keys, database claims, renewable leases, and fencing tokens protect duplicate or stale execution.

Read by task

Task Document
Understand package and process ownership Backend architecture
Preserve dependency direction Module boundaries
Change concurrent or durable work Concurrency model
Decide which process owns work Process roles
Add routes, adapters, tasks, or services Extension guide
Change an HTTP contract API conventions

Before a large change, identify the owner process, source of truth, retry and idempotency behavior, and the test that proves the boundary remains intact.