How to Structure Your Microservices
summary
Explains how Monzo runs over 1500 microservices in Go with 99.999% uptime and what actually makes that work: identical service structure, autogenerated boilerplate, a shared domain library (money as big.Int), a single-owner datastore per service, and deploy patterns like blue/green on Kubernetes. Recommends 2–15 business operations per service, event-driven chunks for isolation, observability and API contract tests, and a mono repo plus shared typhon router for consistent behavior and fast large-scale refactors.
AI-written summary · about
chapters (18)
- 0:00Introduction
- 5:25Human body analogy
- 7:15Model network
- 8:25Ground rules
- 9:45Embrace the libraries
- 11:45Money example
- 13:03Gems of wisdom
- 13:27Deciding when something beats on
- 15:40Keep your services small
- 16:18Build extensible systems
- 17:45Dont do this
- 18:22Extend
- 19:16Fail
- 20:34Write tests
- 21:37Mono repo
- 24:29Assigning ownership
- 26:29Quote
- 26:55Outro
related talks
01h 03mGo & Microservices
51mMicroservices in Go
01h 02mBuilding Microservice Architectures with Go
01h 00mSix Secrets to Succeeding with Microservices
43mGo micro with Microservices
28mMicroservices – Boyan Dimitrov
47mMicroservices? Monoliths? An Annoying Discussion!
45mGo, Microservices and all the joy!