Versioning in a Microservice Architecture
summary
Real-world system at an e‑commerce operator implements a build-time dependency graph created from code annotations and Docker builds, tracks versions as a version vector across code, DB, frontend bundles and message schemas, and refuses deployments that remove an API still in use. Teams use simple counting rather than semantic tags because services deploy multiple times a day. Queue and event versions require duplicate messages for backward compatibility. Front-end composition with HTML partials and JS assets causes asset bloat and conflicts; a dedicated renderer that aggregates data instead of partial HTML proves preferable.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 1:17What is Microservice
- 4:30Frontend
- 11:15API
- 12:24Dependencies
- 17:42Data Structures
- 21:02Backend
- 23:28Conclusion
- 24:28Questions
- 27:33Frontend versioning
related talks
52mI Have a Microservices Architecture and I Didn't Know.
27mArchitecting for Change Debate
57mForking the Future: Embracing Microservices Evolution
40mMicroservice Architecture with Reusable Components
51mMicroservices and Microfrontends: Scaling, Learning, Growing
45mMicroservices: A retrospective
16mMicroservice Challenges
34mMicroservices, but what about the UI