Summary of "Design Microservice Architectures the Right Way"
High-level summary
This talk is a practical guide to designing scalable, maintainable microservice architectures, grounded in the presenter’s experience as CTO/co‑founder of Flo Commerce and previously Gilt. The emphasis is on making microservices simple to develop, test, deploy and evolve—so small changes (for example, changing a URL) don’t become weeks‑long projects.
Core thesis: treat API/event schema design, code generation, testing, deployment automation and dependency management as first‑class artifacts. Invest up‑front and automate everything that can be automated.
Key misconceptions addressed
-
Polyglot freedom Letting teams pick any language/framework is very expensive. Successful polyglot environments require large, dedicated investment and tooling.
-
Code generation is “evil” When done well, code generation produces readable, trusted artifacts that reduce ad‑hoc client code and drift.
-
Event log must replace DB reads Services should own their databases (the source of truth) and publish events. Local DB reads are fine if you guarantee events are published (at‑least‑once semantics).
-
Developers can only maintain ≤3 services If engineers are limited to that by cognitive load, it signals missing automation and tooling. Better tooling lets developers safely own more services.
Architectural principles and patterns
API‑first, schema‑first
- Define every REST API and event schema in a language‑neutral spec (JSON used in the talk).
- Store specs centrally (an API repo), not split across service repos.
- Model resources, resource forms, and operations explicitly.
- Use annotations (e.g., GDPR/personal‑data flags) in specs to drive cross‑service visibility and compliance.
Continuous validation
- Run API specs through CI with linters and breaking‑change detection before code is written.
- Catch breaking changes early when they’re cheap to fix.
Code generation
- Generate routes, client libraries and mock clients from specs to:
- Guarantee implemented endpoints match the spec (compiler errors if not).
- Provide idiomatic client libraries so teams don’t write ad‑hoc clients.
- Produce high‑fidelity mocks for fast local and integration testing.
- Make generated artifacts readable and trusted.
Databases
- One private database per microservice; no direct cross‑service DB access.
- Generate DB schemas from metadata via codegen with company‑wide conventions (e.g., non‑empty trimmed strings).
- Apply global optimizations (e.g., hash checks to avoid updating unchanged records) across services via codegen.
Testing
- Invest heavily in generated mocks, end‑to‑end integration tests (Play framework example), and test factories.
- Run tests locally and in CI; aim for high confidence so “code moves to production and just works.”
Continuous Delivery
- Essential for microservices; deploys triggered by git tags (automatic tagging on master changes).
- Aim for fully automated, reliable pipelines.
- Keep deployment configuration minimal and self‑documenting (small YAML files).
- Standardize health check endpoints (driven by the API spec) to gate instance readiness.
- Example tool: Delta — a small open/infra tool used to orchestrate tagging/build/deploy and monitor desired state.
Events
- Schema‑first event design; prefer formats and tooling that enforce schema correctness (binary formats like gRPC or co‑generated JSON).
- Semantics: producers guarantee at‑least‑once delivery; consumers must be idempotent.
- Implementation pattern:
- Each service journals all table operations (insert/update/delete).
- Journal records are queued and published to a streaming system (Kinesis or equivalent).
- Consumers read from the stream, insert events into a local queue/db, process in micro‑batches, and log/monitor failures.
- Local consumer storage makes retries and replays easy.
- Event streams and ownership:
- Union types map to a single stream; each stream is owned by exactly one service.
- Linters enforce required fields (timestamp, organization, etc.) and consistent structure to enable programmatic operations (analytics, warehouse ingestion).
- Typical end‑to‑end latency: ~0.5s (suitable for most use cases).
Operational and developer tooling
- Central CLI (dev) to create environments, databases, etc., reducing tribal knowledge and human error.
- Metadata‑driven DB creation and partitioning (e.g., journaling partitions with retention policies).
- Monitoring and error visibility: treat failures as first‑class with notifications and local event storage for easy replay after fixes.
- Standardized, minimal deployment manifests and health checks derived from API spec.
Dependency management strategy
- Pay a recurring “tax” to keep dependencies up to date instead of letting them rot.
- dependency‑flo (open source) crawls projects, extracts dependencies, tracks versions, and recommends/upgrades with near‑zero false positives; it can create PRs automatically.
- Run weekly automated dependency upgrades: PRs are created, tests run, and a green PR → deploy. This reduces security/bug patch rollout time from weeks to hours.
Practical, actionable guidance
- Make API/event schema the first artifact—store specs centrally and lint/CI them.
- Code‑generate routes, clients and mocks; make generated artifacts readable.
- Give each microservice an exclusive DB; communicate only via APIs/events.
- Automate testing at all levels: unit, mock integration, end‑to‑end. Trust tests enough to practice TDD in production (production checks/crons).
- Implement robust, fully automated continuous delivery that is easy to operate.
- Implement event journaling and local consumer storage patterns for reliable async processing and easy replay.
- Invest in dependency automation so upgrades are routine, not painful.
- Prefer consistency and convention over scattered creativity in infra/database definitions—apply company‑wide policies via metadata/codegen.
Tools, platforms and references mentioned
- API Builder (open source) — API design + linters + codegen
- Delta — small CD orchestrator used by the presenter’s team
- dependency‑flo — dependency tracking and automated PR generation
- AWS RDS, Kinesis (streaming), PostgreSQL (with partitioning/journaling libraries)
- Play framework and Scala examples (routes, clients, tests)
- gRPC — binary format that encourages co‑generation and schema correctness
- Jay Kreps — referenced for Kafka / “Log as a Streaming Platform” ideas
Main speakers and sources
- Presenter: Flo Daioh — co‑founder and CTO of Flo Commerce; former co‑founder and CTO of Gilt
- Tools/works referenced: API Builder, Delta, dependency‑flo; paper/ideas from Jay Kreps (Kafka/log as a streaming platform)
Category
Technology
Share this summary
Is the summary off?
If you think the summary is inaccurate, you can reprocess it with the latest model.