Scaling Horizons Effective Strategies for Wix's Scaling challenges
summary
Wix runs ~4,000 microservices and handles 3.5 billion daily HTTP transactions and 70 billion Kafka messages, so scaling choices are concrete: deploy per-Kafka-cluster consumer proxy fleets to cut managed-Kafka cost and avoid single points, split web traffic into editor vs public segments at the load balancer, use QoS fleets (three groups) for noisy webhook tenants, choose DynamoDB for auto-sharding while respecting its limits (DynamoDB partitions: 10 GB / 3k RCU / 1k WCU), and use ProxySQL query hints for geo routing to support MySQL geo-shards — horizontal scaling reduces single-node limits but increases operational complexity.
AI-written summary · about
chapters (9)
- 0:00Introduction and speaker intro
- 3:18Vertical vs horizontal scaling
- 8:18Fixed routing strategies
- 17:15Wix web traffic segmentation
- 20:08Dynamic routing for reactions app
- 28:57Data sharding with DynamoDB
- 31:53Geo-based data locality for enterprises
- 34:42Key takeaways and scaling summary
- 40:46Q&A session
related talks
51mScaling Wix with microservices architecture
46mLessons Learned From Working with 2000 Event-Driven Microservices
54mLessons learned from working with 2000 event-driven microservices
41mBattle-tested event-driven patterns for your microservices
37mKafka Based Global Data Mesh at Wix
30m8 Lessons Learned from using Kafka with 1000 microservices
43mBattle-tested event-driven patterns for your Microservices archit.
36mThe Art of Decomposing Monoliths
