ADR 0011 — Premium "fully-hosted workflow" tier: Fargate + Firecracker microVM candidate

Status: Superseded by ADR 0013; premium-tier compute decision deferred to a separate future ADR (2026-04-22) Original date: 2026-04-22 Deciders: product owner (user), software-architect Related: ADR 0008 (OAuth), ADR 0009 (token posture), ADR 0010 (v1 compute), docs/architecture/multi-tenant-alpaca.md §7, §8 Parent epic: #183

Supersede note (2026-04-22): This ADR sketched premium-tier compute for user-authored strategies running against the user's live Alpaca account via user-scoped OAuth. Under the MBT reframe (ADR 0013), the premium compute question re-frames to: "Dedicated compute running MQ-A strategies against MBT's simulator + shared market data + optional live-handoff to a user's broker." That reframes the token-flow (tasks never hold a live-broker token; they call back to Raptor, and in most cases the task is trading against MBT, not a live broker at all). Fargate + Firecracker remains a plausible platform candidate, but the ADR needs to be re-written from scratch with the new token-flow. Content preserved for historical traceability; the new ADR will be filed when premium-tier is scoped.

Context (original)

Premium tier sketch: user-authored MQ-A strategies run server-side on schedule or market event, place orders on the user's behalf via their Alpaca OAuth token, survive disconnect. Reference: QuantConnect's live-node model.

Decision (original — now superseded)

Candidate platform: AWS Fargate, one task per live strategy, Firecracker-microVM-isolated.

Key elements:

Each task runs hardened Python runtime in its own microVM.
Task does not hold Alpaca OAuth token; calls back to Raptor to mint short-lived sub-token per broker interaction.
Triggers via EventBridge + MarketDataHub pub/sub + user's trade-update stream.
DSL-only at launch; Python deferred.
Warm-pool at market open; per-task CPU/RAM/wall-clock/order-count caps.

Why superseded (and re-scoped)

The reframe changes the primary use case:

Most "premium strategies" run against MBT (paper), not the user's live broker. This is the default posture because (a) MBT is where most users are, (b) paper-first gating is our invariant, (c) regulatory posture is cleaner (user-directed simulation).
Live-broker routing is the exception, not the rule. When it happens, the handoff is per-order and already audited; the task calls back to Raptor exactly as the original ADR described.
Market data is shared (one server-side Alpaca key, not per-task, not per-user OAuth). This simplifies the task's runtime dependency surface.
The token-minting callback pattern from the original ADR still applies, narrowed to live-handoff submissions.

Premium compute platform decision is deferred to a future ADR that will be written when the premium-tier product is scoped. Fargate + Firecracker remains a candidate; Cloud Run, K8s + gVisor, and wasmtime all stay in the alternatives pool. Cost economics shift under the reframe because most tasks will be trading against MBT — no Alpaca rate-limit pressure, and tighter CPU/RAM budgets suffice.

Regulatory flags from the original ADR remain open and are covered in multi-tenant-alpaca.md §6 and mbt-paper-trading-engine.md §13. Counsel consult still required before hosted-strategy GA.

Alternatives considered (still valid)

AWS Fargate, Google Cloud Run, Self-managed K8s + gVisor, K8s Jobs, wasmtime — all remain in the alternatives set for the future ADR. See original file history for analysis.

Revisit when

Premium-tier product spec is written → new ADR supersedes this one.
MBT v1 ships and produces real operational cost data.
Regulatory flags (Advisers Act §202(a)(11), copy-trading) resolve with counsel.