Status: Superseded by ADR 0013 (2026-04-22)
Original date: 2026-04-22
Deciders: product owner (user), software-architect
Related: ADR 0008 (OAuth integration mode), ADR 0009 (token posture), ADR 0011 (premium-tier compute), docs/architecture/multi-tenant-alpaca.md §5
Parent epic: #183
Supersede note (2026-04-22): ADR 0010 decided the v1 runtime posture assuming every user's trades routed through Alpaca OAuth. Under the MBT reframe (ADR 0013), the primary runtime question is not "how do we scope an Alpaca token per request" but "how does MBT's order matcher serve many users in one shared process." The answer remains shared single-process Raptor with per-user scoping — but the scoping attribute is now
{user_id, account_id}against MBT's own tables, not an Alpaca OAuth connection. ADR 0013 restates the posture for MBT. Content preserved for historical traceability.
Multi-tenant Raxx needed to decide how per-user work is executed server-side. Options span a spectrum from shared single-process through microVM-per-user. Original ADR decided:
v1 runs a shared single-process Raptor backend. Per-user isolation is by OAuth scope + authz + request tracing, not by compute boundary.
Execution model:
user_id via the session table.alpaca_connections row, decrypted the token via KMS, and constructed a per-request Alpaca client.Under MBT:
user_id foreign key + session-attached user) against the same Flask process.docs/marketing/pricing.md). See docs/architecture/session-engine.md §6.env=live submit-to-broker action as well as credential changes).The shared-process choice remains correct; the scoping attribute shifts. ADR 0013 restates the current posture.
Carried over to ADR 0013.
N/A — superseded. Amendments go on ADR 0013.