- Newest
- Most votes
- Most comments
I have few observations on the architecture:
1. API Gateway → Lambda → Aurora Direct Write Pattern
Synchronous blocking: Each API request waits for the database write to complete, increasing latency
No buffering: Sudden traffic spikes directly hit Aurora, potentially overwhelming the database
Limited throughput: Lambda concurrency limits could bottleneck high-frequency trading operations.
Cold start impact: Lambda cold starts add unpredictable latency to time-sensitive trades
2. Missing Resilience Details For a trading application, the architecture lacks critical resilience components:
Circuit breakers: No mention of retry logic, exponential backoff, or failure isolation
Rate limiting: Beyond WAF, no API-level throttling or quota management
Data consistency: No discussion of transaction handling during failover scenarios
RTO/RPO targets: No defined recovery time/point objectives
Connection pooling: Lambda's ephemeral nature makes database connection management challenging
Idempotency: Critical for trading - no mention of duplicate transaction prevention
Time stamping the trades is very critical. You may refer the blog post How Derive scaled their low-latency, decentralized trading platform using AWS Graviton, Amazon EKS, and Amazon Aurora about handling trade latency.
Relevant content
- asked 4 years ago
- asked 6 months ago
- asked 2 years ago
- AWS OFFICIALUpdated 3 years ago
