The position manager is a state projection over append-only synthetic events. It monitors freshness, unresolved cases, paper limits, review expiry, and data-quality warnings. It has no network client and no action button. Every proposed change becomes a new paper event after validation.
Model a state machine: PROPOSED, PAPER_OPEN, PAPER_EXIT_SCENARIO, RESOLVED, VOIDED, and QUARANTINED. Define allowed transitions in code. For example, RESOLVED cannot return to PAPER_OPEN; a correction appends a new resolution-version event and marks the projection disputed until reviewed.
Each monitoring cycle reads a sealed snapshot bundle, checks quote age, policy version, approval expiry, theme limits, and resolution evidence, then appends observations. It never silently refreshes a mark. If the run is incomplete, all affected positions receive a visible health warning.
Calculate derived fields by replay: fictional points tied up, latest mark scenario, age, theme exposure, pending review, and event-chain status. Cache the projection for speed but reconcile it against replay regularly. A mismatch stops publication.
Operational alerts describe system failures: “snapshot stale,” “reconciliation mismatch,” or “approval expired.” They do not say buy, sell, opportunity, or profit. Deduplicate alerts by issue key and send recovery notices when resolved.
Concurrency needs optimistic version checks or transactions. Two workers evaluating the same position must not append conflicting transitions. Use a unique event key and a projection version; on conflict, reload and reevaluate.
Define health invariants for each cycle: every open position has a valid approval and source hash, total fictional points reconcile, no theme exceeds its limit, every projection event exists in the audit chain, and dashboard age matches the latest sealed run. Run them before publishing. A failed invariant quarantines the affected portfolio and creates one deduplicated operational incident.
Test restart behavior by terminating between event append and projection refresh. On startup, rebuild from the last sealed event rather than trusting memory. Record recovery duration, number of replayed events, and final hash. This turns crash recovery into repeatable evidence instead of a reassuring assumption.
🇵🇰 Pakistan Angle
Show timestamps in UTC and Pakistan time, and design the local dashboard to survive offline periods. No learner identity or financial details are required. The artifact demonstrates monitoring and event-state engineering useful beyond finance.
Hands-On Exercise
Implement the state machine and replay projection. Test valid and invalid transitions, concurrent duplicate cycles, stale data, expired approval, correction, and corrupted cache. Generate a health dashboard and prove alerts contain operations language only.
Completion Rubric
- Allowed transitions are explicit and tested.
- Projection derives from immutable events and reconciles.
- Concurrent cycles are idempotent and conflict-safe.
- Alerts communicate failures, never actions or outcomes.
- Manager contains no external transaction capability.
Sources
Key takeaway: Monitoring is trustworthy when state is replayable, transitions are constrained, and alerts remain operational.