Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
OptionChain-Simulator API and Architecture
System Architecture
flowchart TD
Client[Client Applications] --> API[API Layer]
API --> SM[Session Management]
SM --> App[Application Layer]
App --> Domain[Domain Layer]
App --> Infra[Infrastructure Layer]
Domain --> SimEngine[Simulation Engine]
Infra --> ClickHouse[(ClickHouse DB)]
Infra --> Redis[(Redis)]
Infra --> MongoDB[(MongoDB)]
Session State Transitions
stateDiagram-v2
[*] --> Initialized: POST /api/v1/chain
Initialized --> InProgress: POST /api/v1/chain/step
InProgress --> InProgress: POST /api/v1/chain/step
InProgress --> Modified: PATCH
Modified --> InProgress: POST /api/v1/chain/step
InProgress --> Reinitialized: PUT
Modified --> Reinitialized: PUT
Reinitialized --> InProgress: POST /api/v1/chain/step
Initialized --> [*]: DELETE
InProgress --> [*]: DELETE
Modified --> [*]: DELETE
Reinitialized --> [*]: DELETE
GET /api/v1/chain is a safe, repeatable peek and does not appear here because it
never changes the session state — only POST /api/v1/chain/step advances the cursor.
API Request Flow
sequenceDiagram
participant Client
participant API as REST API
participant SM as Session Manager
participant SS as Simulator Service
Client->>API: POST /api/v1/chain
API->>SM: Create new session
SM->>SS: Initialize simulation
SS-->>SM: Initial state
SM-->>API: Session created (id: abc123)
API-->>Client: 201 Created (session details)
Client->>API: POST /api/v1/chain/step
API->>SM: Advance one step
SM->>SS: Advance simulation
SS-->>SM: Step data
SM-->>API: Chain data
API-->>Client: 200 OK (Chain data)
Client->>API: GET /api/v1/chain
API->>SM: Peek current step
SM->>SS: Read current snapshot
SS-->>SM: Step data (no advance)
SM-->>API: Chain data
API-->>Client: 200 OK (same snapshot, repeatable)
REST API Endpoints
The OptionChain-Simulator exposes the following REST API endpoints:
| Method | Endpoint | Action | Description |
|---|---|---|---|
| POST | /api/v1/chain | Create Session | Creates a new simulation session |
| GET | /api/v1/chain | Read Current Step | Returns the snapshot the next advance will serve (safe, repeatable) |
| POST | /api/v1/chain/step | Advance Step | Serves the snapshot at the cursor (index 0 first), then advances |
| PUT | /api/v1/chain | Replace Session | Completely replaces session parameters |
| PATCH | /api/v1/chain | Update Parameters | Updates specific session parameters |
| DELETE | /api/v1/chain | Delete Session | Terminates and removes a session |
Step cursor semantics (serve-then-advance): current_step is the 0-based index
of the NEXT snapshot to serve. POST /api/v1/chain/step serves the snapshot at the
cursor and then advances it, so a session with steps = N serves EXACTLY indices
0..N-1 over N advances. The advance that serves the last snapshot persists the
Completed state, and any further advance returns 410 Gone. GET /api/v1/chain
peeks the snapshot the next advance would serve without moving the cursor.
Migration (breaking, issue #21):
GET /api/v1/chainused to advance the session and consume a step. It is now a read-only, repeatable peek that returns the current snapshot without mutating state. To advance the cursor, clients must now callPOST /api/v1/chain/step(same response shape, same 200/404/410/500 status codes as the old GET). Downstream consumers such as IronCondor must switch their step-advancing call fromGET /api/v1/chaintoPOST /api/v1/chain/step.
v2 rolling simulations
/api/v2/simulations is a second, parallel REST surface for deterministic
rolling multi-expiration simulations: a simulated clock instead of a
wall-clock timestamp, a rolling inventory of absolute expirations driven by
versioned schedule rules (0DTE / weekly / monthly / yearly), and one
snapshot per cursor position.
| Method | Endpoint | Action |
|---|---|---|
| POST | /api/v2/simulations | Create a simulation and receive every replay input |
| GET | /api/v2/simulations/{id} | Read its metadata and effective parameters |
| GET | /api/v2/simulations/{id}/snapshot | Peek the current snapshot (safe, repeatable) |
| POST | /api/v2/simulations/{id}/step | Serve the current snapshot, then advance once |
| DELETE | /api/v2/simulations/{id} | Delete it and evict its cached state |
Serve-then-advance, as in v1: a simulation with steps = N serves
indices 0..N-1 over N calls to /step, and any call after that returns
410 Gone. expected_step on the advance is a precondition — a mismatch is
412 with the actual cursor and consumes nothing, which is what makes a
retry after a lost response safe. It is deliberately distinct from 409,
which means another writer committed first.
A v2 simulation is immutable after creation. There is no PATCH or PUT: changing the seed, the start, the schedules or the chain shape changes the tape, so it creates a new simulation instead of mutating one.
A historical v2 walk prices itself. A Historical method carries no
volatility of its own, so each step is priced by the realized volatility of
everything observed up to that step and nothing later — the same expanding
window v1 uses, so from step 1 on the two agree on the volatility path as
well as the price path. (Step 0 differs by construction: v1 prices its first
chain at the request's constant.) The volatility you send prices none of
its steps; the values that did are the per-step ones every snapshot and the
volatility export report. A series too turbulent to price a chain at, or
one whose first three prices are equal, is refused when the simulation is
first served.
Advanced steps can be filed in ClickHouse. With
OCS_SNAPSHOT_PERSISTENCE_ENABLED on, every step an advance serves is
written as one metadata row plus one flattened row per expiration and
strike, so a client can query one contract across time instead of unwinding
whole documents. A peek and an export replay and persist nothing — only the
advance, which is the call that moves the cursor, files anything.
Filing happens after the cursor commits and off the request's clock, so
a degraded warehouse can neither fail a response nor delay one. Row identity
is derived from (simulation, tape generation, step), which makes a retry
replace a row rather than duplicate it, and a reader never sees a snapshot
whose quote rows are missing — the metadata row carries the expected count
and a mismatch reads as absent. Turning the knob on makes ClickHouse a hard
startup dependency: the tables are created at boot, so a schema or
connectivity problem fails the boot rather than surfacing later. MongoDB
stays event and audit only.
Replay. The creation response echoes the effective seed, effective start, step interval, time frame, timezone, calendar version, IANA tzdb release and normalised schedules — everything needed to reproduce the run without having kept the request. The full contract is in ADR 0001.
/api/v1/chain is frozen. Its routes, DTO fields and types, wall-clock
timestamp behaviour, rendered values, status codes and OpenAPI operations
are byte- and behaviour-compatible; v2 ships as a separate surface with its
own session type and its own stored-session schema, so existing clients
need no changes.
Configuration
Every environment variable the service reads is documented in
.env.example with its default and accepted range. Two families, with
deliberately different failure behaviour:
- Request caps —
OCS_MAX_STEPS,OCS_MAX_CHAIN_SIZE,OCS_MAX_HISTORICAL_PRICES,OCS_MAX_CACHED_WALKS— warn and fall back to their defaults when set to something invalid. A bad value there degrades one request. - v2 operational knobs —
OCS_V2_RETENTION_SECS,OCS_V2_CLEANUP_INTERVAL_SECS,OCS_MAX_CACHED_TAPES,OCS_MAX_CACHED_SNAPSHOTS,OCS_MAX_CACHED_SNAPSHOT_CONTRACTS,OCS_MAX_EXPORT_ROWS,OCS_SNAPSHOT_*— are validated at startup and fail the process with a message naming the variable. Silently reverting a retention window would expire simulations a client is still walking, and silently reverting a cache bound would change the service's memory profile with nothing to show for it.
v2 retention is real time, not simulated time. A simulation whose simulated clock spans three years is still walked one request at a time, so its idle window is an operational choice independent of the horizon. It defaults to an hour — longer than v1's thirty minutes — and is measured from the last write: peeking a snapshot persists nothing, so a client that only peeks does not refresh it. The in-memory and Redis backends apply the same window from the same constant.
A retention sweep runs every OCS_V2_CLEANUP_INTERVAL_SECS, reaping expired
simulations and evicting the factor tapes and snapshots they left behind.
Eviction is never observable in what is served: both rebuild identically
from the effective parameters, so it costs latency and nothing else. The
sweep publishes v2_simulations_expired_total, and the caches publish
v2_tape_cache_size and v2_snapshot_cache_size.
Exporting a tape
GET /api/v2/simulations/{id}/export?dataset=…&format=…&from_step=&to_step=
replays a simulation and streams it, which is what turns a
walked-one-request-at-a-time simulation into something a backtester loads in
one go.
| Parameter | Values |
|---|---|
dataset |
underlying | volatility | option_chains |
format |
json | csv |
from_step, to_step |
inclusive bounds; default to the whole tape |
Read-only in the strong sense. The export takes an immutable snapshot of the effective parameters and replays from those: it never advances the cursor, changes the state or version, or alters what the next peek returns. A simulation that has never been walked exports its whole tape, a completed one still does, and two clients can export the same simulation at once.
Deterministic. Repeating an export is byte-identical: every value is a
function of the effective parameters and the cursor, timestamps render as
whole-second RFC 3339, and numbers use shortest round-trip formatting with
no locale. JSON is a single valid array; CSV is RFC 4180 with a header row
and CRLF endings, and an absent optional is an empty field rather than
null or 0. Chain labels are joined with | so a shared expiration stays
one column.
The rows are produced on a blocking thread and handed over a bounded
channel, so a long option_chains export never occupies an Actix worker and
a slow client applies backpressure instead of accumulating priced chains in
memory. OCS_MAX_EXPORT_ROWS bounds how many steps one request may cover.
Request/Response Models
1. Create Session (POST /api/v1/chain)
Request Body:
Response (201 Created):
2. Peek Current Step (GET /api/v1/chain?sessionid=6af613b6-569c-5c22-9c37-2ed93f31d3af)
Safe and repeatable: returns the session's current snapshot without advancing the
cursor or persisting anything. To advance the session and consume a step, use
POST /api/v1/chain/step?sessionid=... (issue #21) — it takes the same query
parameter and returns the same body shown below.
Response (200 OK):
3. Update Session Parameters (PATCH /api/v1/chain?sessionid=6af613b6-569c-5c22-9c37-2ed93f31d3af)
Request Body:
Response (200 OK):
4. Replace Session (PUT /api/v1/chain)
Request Body:
Response (200 OK):
5. Delete Session (DELETE /api/v1/chain?sessionid=6af613b6-569c-5c22-9c37-2ed93f31d3af)
Response (200 OK):
Domain Models
classDiagram
class SessionManager {
+createSession(params) Session
+getNextStep(id) (Session, OptionChain)
+updateSession(id, params) Session
+reinitializeSession(id, params) Session
+deleteSession(id) bool
}
class Session {
+id UUID
+createdAt DateTime
+updatedAt DateTime
+parameters SimulationParameters
+currentStep usize
+totalSteps usize
+state SessionState
+advanceStep() Result
+modifyParameters(params)
+reinitialize(params, steps)
}
class SessionState {
<<enumeration>>
Initialized
InProgress
Modified
Reinitialized
Completed
Error
}
class SimulationParameters {
+symbol String
+initialPrice Positive
+volatility Positive
+riskFreeRate Decimal
+strikes Vec~Positive~
+expirations Vec~String~
+method SimulationMethod
+timeFrame TimeFrame
}
class Simulator {
+simulateNextStep(session) OptionChain
-createRandomWalk(session) RandomWalk
}
class OptionChain {
+underlying String
+timestamp DateTime
+price Positive
+contracts Vec~OptionContract~
}
class OptionContract {
+strike Positive
+expiration String
+call OptionData
+put OptionData
+impliedVolatility Positive
+gamma Positive
}
Session --> SimulationParameters
Session --> SessionState
SessionManager --> Session: manages
SessionManager --> Simulator: uses
Simulator --> OptionChain: produces
OptionChain --> OptionContract: contains
Infrastructure Components
classDiagram
class SessionStore {
<<interface>>
+get(id) Session
+save(session) void
+delete(id) bool
+cleanup() int
}
class InMemorySessionStore {
-sessions Map~UUID, Session~
+get(id) Session
+save(session) void
+delete(id) bool
+cleanup() int
}
class RedisSessionStore {
-client RedisClient
+get(id) Session
+save(session) void
+delete(id) bool
+cleanup() int
}
class HistoricalDataRepository {
<<interface>>
+getHistoricalPrices(symbol, timeframe, startDate, endDate) Vec~Positive~
+listAvailableSymbols() Vec~String~
+getDateRangeForSymbol(symbol) (DateTime, DateTime)
}
class ClickHouseHistoricalRepository {
-client ClickHouseClient
+getHistoricalPrices(symbol, timeframe, startDate, endDate) Vec~Positive~
+listAvailableSymbols() Vec~String~
+getDateRangeForSymbol(symbol) (DateTime, DateTime)
}
SessionStore <|.. InMemorySessionStore: implements
SessionStore <|.. RedisSessionStore: implements
HistoricalDataRepository <|.. ClickHouseHistoricalRepository: implements
🚀 Deploy the project
To deploy the services defined in Docker/docker-compose.yml, run the following command:
This will:
- Build the Docker images (
--build) - Force container recreation (
--force-recreate) - Run everything in detached mode (
-d) - Use
optionchain-simulatoras the project name to namespace containers and resources
Make sure Docker and Docker Compose are installed and running on your system.
Makefile Commands for Development
The project includes a Makefile with useful commands for development:
| Command | Description |
|---|---|
make build |
Builds the project |
make release |
Builds the project in release mode |
make test |
Runs all tests |
make fmt |
Formats the code using rustfmt |
make lint |
Runs clippy for linting |
make check |
Runs tests, formatting check, and linting |
make run |
Runs the project |
make clean |
Cleans build artifacts |
make doc |
Generates documentation |
make coverage |
Generates code coverage report |
make bench |
Runs benchmarks |
make deploy |
deploy the services in local |
Additional commands for CI/CD and deployment:
| Command | Description |
|---|---|
make pre-push |
Runs fixes, formatting, linting, and tests before pushing |
make workflow |
Runs all GitHub Actions workflows locally |
make publish |
Publishes the package to crates.io |
make zip |
Creates a ZIP archive of the project |
Contribution and Contact
We welcome contributions to this project! If you would like to contribute, please follow these steps:
- Fork the repository.
- Create a new branch for your feature or bug fix.
- Make your changes and ensure that the project still builds and all tests pass.
- Commit your changes and push your branch to your forked repository.
- Submit a pull request to the main repository.
If you have any questions, issues, or would like to provide feedback, please feel free to contact the project maintainer:
Joaquín Béjar García
- Email: jb@taunais.com
- GitHub: joaquinbejar
We appreciate your interest and look forward to your contributions!
✍️ License
Licensed under MIT license