Scaling Wix with microservices architecture
summary
Claims scaling a 74M-user site serving 2PB of static files and ~2B HTTP requests/day by splitting into editor/public/media segments, using immutable revisions and pushing 3-month-old sites into a slower archive DB to limit MySQL ops. Media platform runs multi‑cloud (Google + Amazon + own DC) with five replicated copies of pages, CDN fallback and an async mirror; pages render via client-side rendering (React/Angular) to cut server cost, and the stack uses Jetty, MySQL, Cassandra/Mongo/MongoDB. Regular “game days” test failover; the team reports needing only four servers to render 74M sites under these tradeoffs.
AI-written summary · about
chapters (8)
- 0:00Introduction to Wicks
- 2:27System architecture evolution
- 7:45Microservices design principles
- 14:35Managing site data
- 25:29Media and file serving
- 27:31Public serving and performance
- 35:34Disaster recovery strategy
- 41:29Conclusion and Q&A
related talks
44mScaling Horizons Effective Strategies for Wix's Scaling challenges
36mThe Art of Decomposing Monoliths
54mLessons learned from working with 2000 event-driven microservices
53mPowering 100+ million daily users
45mBuilding Event-Driven Microservices with Event Sourcing and CQRS
33mPros/Cons of Highly Scalable Microservice Systems
54mMigrating to Cloud Native with Microservices
45mAvoiding Microservice Megadisasters