Scaling Production data across Microservices
summary
Describes Fiverr’s migration from a LAMP monolith to ~200 microservices and the data-sharing problems that arose when data moved behind REST APIs (performance, reliability, team dependencies). Explains a concrete solution using Kafka as a central data hub, combined with patterns from CQRS and Domain‑Driven Design to share production data across services and enable faster iteration.
AI-written summary · about
chapters (12)
- 0:00Start
- 1:44Trouble maintaining the same cadence
- 2:25monitor for errors and performance issues
- 2:54harder to upgrade our 3rd party dependencies
- 3:39Model View Controller
- 4:01Use the latest tech outside the Monolith
- 4:46complex deploy sequences involving the Monolith and several Microservices
- 11:13Can we avoid the coupling to the source database?
- 21:08orchestration vs choreography • shift to choreography
- 23:45compete order by user business flow
- 24:56key take-aways: . Practice evolutionary architecture • Respect the Data Dichotomy
- 25:54key take-aways: . State Change Events Read optimized views decouple querying patterns and increase performance . They are not mutually exclusive and their Ordering is important!
related talks
44mA Software Engineer's Journey Through Microservices Data Sharing
53mHow do we build high‑load microservices
36mMicroservices Lessons Learned
54mFrom a distributed monolith to a microservices solution
49mChallenges in Implementing Microservices
29mMoving from A and B to ~150 microservices, the journey and learnings
50mChallenges in Implementing Microservices
25mData-Driven Migration from Monoliths to Event-Driven Microservices
