Scaling Rails API to Write-Heavy Traffic
summary
Mobile-game backends serve tens of millions of users and millions of DB transactions per minute by using multiple databases with sharding, manual read/write switching, DNS-based service discovery and weighted sampling for dynamic shard allocation. Rails apps run on MySQL with replication (Rails 6 read‑your‑write 2s default), resource-focused API responses include affected resources to avoid reads, and partial resharding or pool/push/double-write patterns keep locality. Practical additions: connection pooling fixes, at‑least‑once message queues, real multi‑DB load tests; result is high write scalability with tolerable eventual consistency.
AI-written summary · about
chapters (11)
- 0:00Start
- 3:17Mobile Game API Backends: System Overview
- 25:47Scenario: Join a Guild and Defeat a Raid Boss
- 26:25Solution: Partial Resharding
- 29:08Overview of 2 Phase Commit for Comparative Study
- 32:02Reduce Risk of Cross-Shard Transaction Anomalies
- 35:36Keep Inconsistency Observable and Acceptable
- 38:12Keep Idempotency and Reach Eventual Consistency
- 40:18Utilize At Least Once Message Queue for Strict Completion
- 50:34Conduct Load Test before Service Launch
- 53:53Summary: Scaling Rails API to Write Heavy Traffic
related talks
29mScaling Rails to 2M MySQL requests per second
39mPostgres & Rails 6 Multi-DB: Pitfalls, Patterns, Performance
46mScaling With Friends
31mA Rails performance guidebook: from 0 to 1B requests/day
14mDatabase Performance at Scale for RoR Applications
20mSafely Decomposing a Highly Available Rails App
45mTechnically, a Talk
29mA Rails Performance Guidebook: from 0 to 1B requests/day
