Built for Speed: The Architecture Behind the Platform

A reactive UI that reflects what's actually happening

Toll Booth's interface is built on a server-rendered reactive architecture. The browser updates in real time — without a full page reload — as your positions change, orders fire, or configuration takes effect. There is no polling loop refreshing a stale snapshot every 30 seconds. When a covered-call order is submitted or a position rolls, the dashboard reflects it.

The UI state lives on the server, not in a disconnected front-end layer. That means what you see in the browser is always derived from the actual system state — not a cached copy that may have drifted from reality. For traders who have spent time in other platforms watching a spinner and wondering whether something actually happened, the difference is immediate.

A database designed for the shape of trading data

Financial data is rarely tabular. A covered-call position has legs, an underlying share position, expiration dates, rolling history, per-symbol configuration, and event logs — data that maps poorly to a rigid row-and-column schema.

Toll Booth stores position data in a document-oriented database: each position is a self-contained record that can hold nested structure without forcing the data into a flat table. This means complex queries on multi-leg positions run against data that already reflects how those positions are structured, rather than requiring a join across a dozen tables to reconstruct what is, conceptually, a single thing. The result is faster reads on the data shapes the trading engine actually queries, and less brittle schema logic at the infrastructure layer.

A backend built around jobs, not scripts

The automation engine that drives covered-call scanning, order eligibility checks, rolling logic, and notifications is built on a first-class job queue architecture. Each discrete operation — checking whether a symbol is eligible to open, pricing a new covered call, deciding whether a position should roll — runs as an independent, retryable background job.

This is a meaningful architectural choice. Monolithic scripts that run top-to-bottom fail silently, leave partial state, and give you no visibility into where something went wrong. A job-based pipeline fails at the job level, retries at the job level, and leaves an audit trail at each step. When something behaves unexpectedly, you can trace exactly which gate the order failed at and why — not just observe that a position was never opened.

The same job infrastructure handles concurrent positions without interference. Each symbol's eligibility check and order submission run in isolation, so a slow API response on one symbol does not block another from being processed at the same time.

Stateless, token-based brokerage integration

The connection to your brokerage account uses an OAuth-based authorization flow. You authenticate directly at the broker. Toll Booth never sees or stores your username, password, or account credentials. Access is managed through short-lived, rotatable tokens — if you want to revoke the connection, you do it from the broker's own security settings, and the token immediately stops working.

This is not a workaround or a screen-scraping integration. The authentication model gives the application exactly the permissions required to submit covered-call orders on your behalf — no money-movement permissions, no ability to transfer funds between institutions — and nothing more.

• You sign in directly at the broker; your credentials never touch Toll Booth servers.
• Access and refresh tokens are stored server-side with encryption and rotated on use.
• Revocation is instant and available from the broker's own Security Center or from within Toll Booth.
• All traffic between Toll Booth and the broker API uses TLS. No money-movement permissions are requested.

Why this matters for covered-call automation specifically

Speed and reliability are not just engineering preferences for this type of application — they are functional requirements.

Option pricing changes throughout the trading day. Strike selection involves real-time pricing data. Rolling decisions depend on where a position sits relative to current market values. A system built on slow, unreliable infrastructure does not just deliver a poor user experience: it can miss pricing windows, submit orders based on stale data, or behave inconsistently when conditions change quickly.

Legacy tools often carry architectural debt that makes real-time behavior hard: synchronous request cycles that block on external API calls, shared mutable state that creates race conditions when multiple positions need simultaneous attention, and front-end layers that are decoupled from the backend state they are supposed to reflect.

Toll Booth was built around these constraints from the start — not patched onto a codebase designed for something slower.

Next steps

• How Toll Booth works — step-by-step walkthrough of the automation lifecycle.
• Review pricing — flat monthly subscription with no performance fees.
• Get Started Free — create your account and connect Schwab in minutes.

Disclaimer

This post is educational and does not constitute investment advice. Options trading involves significant risk, including the possibility of losing the entire value of a position. Past performance is not indicative of future results. See Legal and consult a qualified financial professional before trading.