HyperStock.net logo
Vault
Register for 7-day free access
Register for 7-day free access
Blog

Hyperstock technical architecture revealed

Reading time: 12 minutes

overall architecture

User → CDN → Front-end (React) → API Gateway → Service layer → Data source ↓ ↓

PostgreSQL

Redis(cache)

Deployment: AWS + Alibaba Cloud active-active (overseas users use AWS, domestic users use Alibaba Cloud)


AI model selection

Score Scoring model

It's not deep learning, it's a multi-factor weighting model.

Why not use deep learning?

  1. Interpretability: Users ask "Why is this Score high", and I can clearly explain the weight of each dimension.
  2. Data volume: Although there is a lot of option data, the effective annotation data is not enough to train complex models.
  3. Iteration speed: 5 minutes to go online to adjust weights, 5 hours to retrain the model
  4. Stability: Linear models do not suddenly go crazy like neural networks

type structure:

Score = w1×annualized return_score + w2×exertion probability_score +w3×margin efficiency_score + w4×volatility_score + w5×time decay_score where w1=w2=0.25, w3=w4=0.20, w5=0.10

The score of each dimension is a piecewise linear function, not a simple linear function, taking into account the nonlinear characteristics in actual transactions.

May be introduced in the future:

  • Machine learning assisted parameter adjustment (automatic optimization of weights)
  • User behavior feedback closed loop (which recommended users actually use it, fed back to the model)

data source

Options real-time data:

data itemsourceDelay
Option chain quoteOPRA (Options Quotation Authority)< 5 seconds
target pricePolygon.io< 1 second
historical dataSelf-developed databasereal time

Why choose OPRA:

  • Official data source for U.S. options markets
  • Full market coverage (NASDAQ/NYSE/AMEX)
  • Including complete fields such as Greeks, IV, trading volume, etc.

Data processing flow:

OPRA real-time streaming → data cleaning → anomaly detection → storage → API response

Abnormal data alarm (such as price jump > 50%)

SPAN Margin calculation

This is Hyperstock’s unique skill. Most options instruments don't do this.

Implementation method:

  1. Parse CME SPAN parameter file (updated daily)
  2. Simplified calculations for individual stock options (not complete futures portfolio SPAN)
  3. Consider three risk scenarios: underlying price fluctuations, IV changes, and expiration time
  4. Output estimated margin

Discrepancies with mainstream brokerages:

Brokerage firmaverage error95% interval
Interactive Brokers5-8%±12%
Tiger Brokers8-12%±18%
Futu10-15%±22%

Why there is an error:

  • Different brokers add different buffers based on SPAN
  • The position portfolio has a net margin effect (we only count single contracts)
  • Under extreme market conditions, brokers may temporarily increase margins

Performance optimization

Goal: Results within 3 seconds

Optimization means:

Optimization pointsmeansEffect
Database queryOption chains are preloaded into memoryQuery from 2s → 50ms
Greeks calculationCaching + incremental updatesCalculation from 1.5s → 200ms
SPAN calculationCommon scenarios for precomputationCalculation from 800ms → 100ms
API responseRedis cache hot targets< 50ms on hit
Front-end renderingVirtual list + lazy loadingFirst screen < 1s

Actual performance:

  • P50 response time: 1.2s
  • P95 response time: 2.8s
  • P99 response time: 4.1s (very few complex targets)

Bottleneck: When performing multi-standard batch analysis (10 targets at the same time), the calculation time increases linearly. The next optimization step: parallel computing.

Security and Compliance

Data security:

  • Transport: Site-wide HTTPS, TLS 1.3
  • Storage: PostgreSQL AES-256 encryption
  • Password: bcrypt hash, random salt
  • API Key: JWT + expiration mechanism

Service security:

  • DDoS Protection: Cloudflare
  • WAF: Custom rules to filter malicious requests
  • Current limiting: Press API Key to limit current and prevent brushing

Compliance:

  • User transaction data is not stored (only orders placed at brokers)
  • No sensitive personal information is collected
  • Risk warnings cover key pages of the entire site
  • Disclaimer Users must confirm when registering

Technology stack summary

leveltechnologyReasons for selection
front endReact + TypeScript + TailwindType safety, development efficiency
rear endNode.js + ExpressRich ecology, good performance in IO-intensive scenarios
databasePostgreSQL 14Stable, good support for complex queries
cacheRedis 7Hotspot data cache, session storage
message queueNone yet (plan to introduce RabbitMQ)Asynchronous task processing
deployDocker + AWS ECSContainerization, elastic scaling
monitorPrometheus + GrafanaOpen source and customizable
CDNCloudflareFree tier is enough, DDoS protection

How to maintain

automation.

  • CI/CD: GitHub Actions, push is deployment
  • Monitoring alarms: Prometheus automatically sends emails to mobile phones when exceptions occur
  • Data update: scheduled task, automatically pull SPAN parameter every day
  • Backup: PostgreSQL Automatic backup to S3, retained for 30 days
  • Customer service: 70% of questions are answered in the help center, and the remaining 30% are answered via email and messaging tools

Weekly time allocation:

mattertime
New feature development40%
Bug fix20%
User feedback processing15%
Data analysis/optimization15%
Writing (Blogs/Tutorials)10%

Have a technical question you want to chat about?hyperstock.werich@gmail.com

Complete blog series

Thanks for reading. From entry to advanced, from data to behind the scenes, I hope these contents will be helpful to you.

Return to blog homepage →

Hyperstock.net — Use AI to make every Sell Put more efficient.