Running OpenSearch at Scale in High-Traffic Gaming Systems
summary
Runs OpenSearch as the primary request path for a poker platform ingesting about 3.5 million events/day and ~7TB daily, and shows concrete fixes after queue saturation, GC pauses, and hot shards. Describes JVM heap sizing under write pressure, threadpool tuning for bulk ingestion, shard sizing and rollover, and building a separate write lane plus isolated analytics nodes to prevent fraud detection blind spots and mid-tournament degradation — solution works in production.
AI-written summary · about
chapters (8)
- 0:00OpenSearch at scale intro
- 3:31Why OpenSearch as ingestion point
- 8:11Scaling shared cluster challenges
- 14:51Three production failures and fixes
- 20:10Segregating workloads
- 23:21Infrastructure for peak traffic
- 24:45Monitoring OpenSearch beyond CPU/memory
- 26:29OpenSearch for production workload
related talks
41mScaling Search and Powering Vector-Based Retrieval With OpenSea...
45mMonitoring Your OpenSearch Cluster Effectively
44mScaling OpenSearch at Uber: Operating Resilient, Fault-Tolerant, High-Performance Clus...
44mBringing Down the Cost of Your OpenSearch Clusters
04mOpenSearch Performance and Monitoring
31mMaximize Resource Efficiency with Separated Index and Search Workloads
33mLessons From Migrating To OpenSearch: Shard Design, Log Ingestion, and UI Decisions
43mMulti-tenancy for all workloads