Hyperstock technical architecture revealed
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?
- Interpretability: Users ask "Why is this Score high", and I can clearly explain the weight of each dimension.
- Data volume: Although there is a lot of option data, the effective annotation data is not enough to train complex models.
- Iteration speed: 5 minutes to go online to adjust weights, 5 hours to retrain the model
- 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 item | source | Delay |
|---|---|---|
| Option chain quote | OPRA (Options Quotation Authority) | < 5 seconds |
| target price | Polygon.io | < 1 second |
| historical data | Self-developed database | real 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:
- Parse CME SPAN parameter file (updated daily)
- Simplified calculations for individual stock options (not complete futures portfolio SPAN)
- Consider three risk scenarios: underlying price fluctuations, IV changes, and expiration time
- Output estimated margin
Discrepancies with mainstream brokerages:
| Brokerage firm | average error | 95% interval |
|---|---|---|
| Interactive Brokers | 5-8% | ±12% |
| Tiger Brokers | 8-12% | ±18% |
| Futu | 10-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 points | means | Effect |
|---|---|---|
| Database query | Option chains are preloaded into memory | Query from 2s → 50ms |
| Greeks calculation | Caching + incremental updates | Calculation from 1.5s → 200ms |
| SPAN calculation | Common scenarios for precomputation | Calculation from 800ms → 100ms |
| API response | Redis cache hot targets | < 50ms on hit |
| Front-end rendering | Virtual list + lazy loading | First 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
| level | technology | Reasons for selection |
|---|---|---|
| front end | React + TypeScript + Tailwind | Type safety, development efficiency |
| rear end | Node.js + Express | Rich ecology, good performance in IO-intensive scenarios |
| database | PostgreSQL 14 | Stable, good support for complex queries |
| cache | Redis 7 | Hotspot data cache, session storage |
| message queue | None yet (plan to introduce RabbitMQ) | Asynchronous task processing |
| deploy | Docker + AWS ECS | Containerization, elastic scaling |
| monitor | Prometheus + Grafana | Open source and customizable |
| CDN | Cloudflare | Free 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:
| matter | time |
|---|---|
| New feature development | 40% |
| Bug fix | 20% |
| User feedback processing | 15% |
| Data analysis/optimization | 15% |
| 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.
Hyperstock.net — Use AI to make every Sell Put more efficient.
