Team topologies and the microservice architecture: a synergistic relationship

This talk was given at DDD Europe 2025:

In order to thrive in today's volatile and uncertain world, organizations need to master fast flow: the continuous delivery of a stream of small changes to customers and continuous feedback to development. Two essential enablers of fast flow at scale are Team Topologies - which structures an organization for fast flow - and the microservice architecture, which is an architectural style that enables large scale, fast flow development. But beyond both enabling fast flow, what exactly is the relationship between Team Topologies and the microservice architecture?

In this presentation, I describe the synergistic relationship between Team Topologies and the microservice architecture and how they enable fast flow. You will learn how the microservice architecture supports Team Topologies by enabling teams to work more effectively. I discuss also how to apply Team Topologies patterns in a way that enables the successful adoption of the microservice architecture. You will learn about the teams that the microservice architecture needs.

Transcript

1. @crichardson Team topologies and the microservice architecture: a synergistic relationship Chris Richardson Founder of Eventuate.io Founder of the original CloudFoundry.com Author of POJOs in Action and Microservices Patterns @crichardson chris@chrisrichardson.net adopt.microservices.io Copyright © 2025. Chris Richardson Consulting, Inc. All rights reserved
2. @crichardson Presentation goal Enables Enables
3. @crichardson About Chris http://adopt.microservices.io
4. @crichardson About Chris https://chrisrichardson.net/
5. @crichardson Agenda Team topologies and fast fl ow Architecting for team topologies Modular monoliths and team topologies Microservices: enabling team topologies at scale Microservices platforms
6. @crichardson The software delivery feedback loop Development Production Changes: Features, defects, risk, tech debt Feedback Users IT
7. @crichardson Traditional software delivery: slow feedback loop Feedback Long Occasional Development Production Feedback Users QA Ops Slow Handoff Handoff Lots of meetings
8. @crichardson Volatile Uncertain Complex Ambiguous Building complex applications Often using new, unfamiliar technologies + Slow feedback loops = Build the wrong application, the wrong way
9. @crichardson Fast fl ow for business succe$$ in today’s VUCA world Development Production Continuous stream of small changes, many times a day Continuous feedback and learning https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/developer-velocity-how-software-excellence-fuels-business-performance Users IT
10. Stream-aligned team, e.g. Order Management Team Requirements Develop Test Deploy Code in production Work Small (5-9 people), long lived, High trust/psychological safety Minimal coordination overhead (internally, externally) About Team Topologies: organizational patterns and principles for fast fl ow https://teamtopologies.com/key-concepts Stream-aligned team Platform team Facilitating Collaboration Sometimes Sometimes Enabling Team Platform team API Tools Complicated Subsystem team Stream-aligned team API XaaS Mostly
11. Team Topologies principles Focus on Flow, Not Structure High Trust Is Non-Negotiable Keep Teams Together Respect Cognitive Limits (don’t overload teams) Make Changes Small and Safe (ship daily) Connect Teams Directly to Customers Embrace Complexity, Don't Fight It Foster Continuous Discovery Eliminate Team Dependencies (eliminate handoffs) https://teamtopologies.com/key-concepts
12. @crichardson O VID -19 https://www.ft.com/content/f9356bdc-3102-11ea-a329-0bcf87a328f2 https://www.ft.com/content/3f498e64-1aa6-11ea-97df-cc63de1d73f4 https://techcrunch.com/2019/06/18/the-rise-of-the-gig-economy-helps-london-based-insurtech-zego-to-raise-42m/ The success triangle Process: DevOps/Continuous Delivery & Deployment IT must continuously deliver a stream of small changes to customers Businesses must be nimble, agile and innovate faster S/W VUCA Architecture: ??? Enables Enables Complements
13. @crichardson Agenda Team topologies and fast fl ow Architecting for team topologies Modular monoliths and team topologies Microservices: enabling team topologies at scale Microservices platforms
14. @crichardson Stream-aligned teams own subdomains (a.k.a. bounded contexts) <<subdomain>> Customer Management <<subdomain>> Order Management Owns Owns API <<subdomain>> Delivery Management Owns API Stream-aligned team Requirements Develop Test Deploy Code in production Work Team-sized slice of business functionality Collaboration XaaS Collaboration XaaS Collaboration XaaS
15. @crichardson Breaking API changes => Collaboration <<subdomain>> Order Management <<subdomain>> Customer Management Owns Owns Must collaborate on API design API Breaking change Lock-step change => OR Change is dictated Collaboration
16. @crichardson Enabling X-aaS => Loosely design-time coupled subdomains <<subdomain>> Order Management <<subdomain>> Customer Management Owns Owns Unaffected by changes to the other Autonomous Loosely coupled Degree of design-time coupling = probability of lockstep changes XaaS
17. @crichardson Designing loosely coupled subdomains Implementation Small and stable Larger and unstable https://microservices.io/tags/design-time%20coupling Iceberg X A B C Reason to change Minimize dependencies
18. @crichardson Architecture must enable teams to make decisions unilaterally https://microservices.io/post/architecture/2025/03/23/andrew-harmel-law-architecture-advice-process.html
19. @crichardson Fast fl ow requires a fast, automated deployment pipeline Fast Handle volume of changes
20. @crichardson Domain «Service» Order Management «Service» Consumer Management «Service» Credit Card Payments «Service» Restaurant Management «Service» Accounting «Service» Kitchen Management «Service» Service «Database» Database Uses API Legend Part-of «Service» API Gateway «async» «subscribes to» «async» «async» «async» «async» «sync» «sync» «sync» «sync» «sync» Architecture => Fast deployment pipeline https://microservices.io/post/architecture/2024/04/14/architecture-is-multi-dimensional.html Domain «Service» Order Management «Service» Consumer Management «Service» Credit Card Payments «Service» Restaurant Management «Service» Accounting «Service» Kitchen Management «Service» Service «Database» Database Uses API Legend Part-of «Service» API Gateway «async» «subscribes to» «async» «async» «async» «async» «sync» «sync» «sync» «sync» «sync» Component Repository & Pipeline 3 AZ EKS cluster Ingress managed ALB 3 AZ RDS Aurora React application static resources S3 bucket api.app.acme.com app.acme.com Browser Cloudfront <<service>> Order management API Gateway Managed Apache Kafka React SPA CircleCI deployment pipeline «AWS ECR repository» ftgo-XYZ-service «Github Repository» ftgo/ftgo-XYZ-service Commit Push Image «Github Repository» Kubernetes YAML Kubernetes API EKS cluster Commit Deployment Scenarios Organizes subdomains into components Builds and deploys components Runs components Subdomains Loose design-time coupling Fast deployment pipeline
21. @crichardson Two architectural styles that organize subdomains into components* Monolithic architecture Microservice architecture * + deployment pipelines, repositories, build projects, …
22. @crichardson Agenda Team topologies and fast fl ow Architecting for team topologies Modular monoliths and team topologies Microservices: enabling team topologies at scale Microservices platforms
23. @crichardson Monolithic architecture: one component Production Deployment pipeline Application repository Developer laptop App
24. @crichardson Simple architecture => Starting with a monolith is usually* a good idea * but not always
25. @crichardson Pattern: modular (domain-oriented) monolith => improves team autonomy $ mkdir orders $ mkdir consumers $ mkdir deliveries High autonomy ✅ «Module» Main System operations: createOrder() cancelOrder() findOrderHistory() createConsumer() «Module» Consumer Management «Subdomain» Consumer Management «Aggregate» Consumer «Module» Delivery Management «Subdomain» Delivery Management «Aggregate» Delivery «Aggregate» Courier Consumer team Order team Delivery team Owns Owns Owns «Module» Order Management «Subdomain» Order Management «Aggregate» Order DevOps (Stream-aligned) team Application Owned by all teams Organized around subdomains rather than technology Subdomain
26. @crichardson Lehman’s laws: constant change and growth Large application developed by many teams
27. @crichardson Key limitation: single code base => forces collaboration
28. @crichardson Key limitation: Single technology stack = design-time coupling Example of the architecture advice process
29. @crichardson Key limitation: large organization + application => increased cognitive load Large monolith You Infrastructure Service Other application 3rd party integration Many teams
30. @crichardson Key limitation: single deployment pipeline = bottleneck => slow feedback Frequent changes Long wait time Long lead time = Slow feedback Long processing time
31. @crichardson Agenda Team topologies and fast fl ow Architecting for team topologies Modular monoliths and team topologies Microservices: enabling team topologies at scale Microservices platforms
32. @crichardson Microservice architecture: organize subdomains into two or more components Production Deployment pipeline Service Repo Deployment pipeline Service Repo Deployment pipeline Service Repo Independently deployable Loosely coupled Svc Svc Svc Some system operations span multiple services
33. @crichardson Service is a group of one or more subdomains https://microservices.io/post/architecture/2023/03/26/dark-energy-dark- matter-force-descriptions.html
34. De fi ning characteristic: loosely design-time coupled services https://microservices.io/post/architecture/2023/03/28/microservice-architecture-essentials-loose-coupling.html Customer Service Customer Subdomain Order Service Order Subdomain API Stable Infrequent lock step changes
35. @crichardson De fi ning characteristic: Independently deployable services https://microservices.io/post/architecture/2022/05/04/microservice-architecture-essentials-deployability.html Production Order Service Order Service Deployment pipeline Test in isolation Test Service Test Double Service Sole criteria for release Includes contract- testing to enforce API interoperability Deploy automatically
36. @crichardson Drawback: more complex programming model* * carefully de fi ne service boundaries to minimize problems
37. @crichardson Bene fi t: Stream-aligned teams work independently… Order Management Team Consumer Management Team Delivery Management Team Stream-aligned teams Order Service Consumer Service Delivery Service Loosely design-time coupled, independently deployable services
38. @crichardson … improved team autonomy - separate (loosely design-time coupled) code bases…
39. @crichardson … Separate technology stacks
40. @crichardson Bene fi t: Reduced cognitive load - service = small application Service Small part of a large application Service … Service … Service … collaborators A P I You A P I A P I A P I Service … Service … clients
41. @crichardson Bene fi t: Multiple, faster deployment pipelines => faster feedback Small service => Faster build Small team => Less frequent
42. @crichardson Agenda Team topologies and fast fl ow Architecting for team topologies Modular monoliths and team topologies Microservices: enabling team topologies at scale Microservices platforms
43. @crichardson Using microservices => numerous sub-issues to resolve https://microservices.io/patterns/microservices.html
44. @crichardson Implementing patterns can be a burden
45. @crichardson Solution: Use platforms An artifact that reduces the cognitive load of a stream-aligned team Platform team Stream-aligned team XaaS Mostly
46. @crichardson Microservices Platforms + Teams
47. @crichardson Aim for the Thinnest Viable Platform (TVP) “Most internal platforms become bloated monstrosities that slow teams down rather than accelerate progress. The TVP approach creates platforms that provide just enough capability without unnecessary complexity. A good platform should make stream- aligned teams move faster, not generate more dependencies to manage.” WARNING !
48. Services- fi rst, platforms-later Migrating a monolith to microservices: incrementally de fi ne services initially just a few Focus on the services, not the platforms De fi ne/evolve platforms to solve actual problems Develop services Create unmet needs Build/evolve platform Update services to use platform Start https://microservices.io/post/antipatterns/2019/04/30/antipattern-focus-on-technology.html
49. @crichardson Microservices Platforms: simplifying service creation and maintenance
50. @crichardson Each service needs extensive plumbing
51. @crichardson
52. @crichardson Pattern: Service Template https://microservices.io/patterns/service-template.html
53. @crichardson Drawback: plumbing evolves => update everywhere
54. @crichardson Pattern: Service chassis https://microservices.io/patterns/microservice-chassis.html Framework
55. @crichardson Microservices Platforms: provisioning infrastructure services
56. @crichardson Services need infrastructure services Customer Service Order Service Customer Service DB Order Service DB Apache Kafka (Application) Services Infrastructure Services Service- speci fi c Shared e.g. AWS MSK e.g. AWS RDS e.g. AWS RDS
57. @crichardson Infrastructure Services Platform: Application-wide services AWS MSK Cluster Terraform/Cloud Formation Configuration Configures Infrastructure Services Platform
58. @crichardson Infrastructure Services Platform: Self-service provisioning of service-speci fi c infrastructure Customer Service Helm Chart Self-service provisioning kind: ServiceDatabase meta: name: customer-service-db … Crossplane Composition ServiceDatabase Crossplane CompositeResourceDefinition ServiceDatabase AWS RDS Postgres database <<ServiceDatabase>> customer-serviceDB Crossplane Infrastructure Services Platform Provides guardrails for provisioning a database Extends Kubernetes API with new resource type Kubernetes Cluster
59. @crichardson Microservices Platforms: understanding application behavior
60. @crichardson About observability Users Teams Production Service Observability Infrastructure Telemetry: Logs Metrics Traces Feedback “What’s the behavior of the service and its users?”
61. @crichardson Observability platform Observability patterns Exception tracking Distributed tracing Application metrics Log aggregation Implements Service Template Service Chassis Implements Observability platform Prometheus ELK stack …. Cloud Watch Datadog …. Libraries that are compatible with the observability services Observability configuration Observability libraries Installed or SaaS
62. @crichardson Microservices Platforms: the path from laptop to production
63. @crichardson Build and deployment platforms: deployment pipeline and production environment Container Registry Production Helm Chart Container Image Service deployment pipeline Test in isolation Test Service Test Double Sole criteria for release Includes contract- testing to enforce API interoperability ServiceGit Repository Dev Flux K8s API Application configuration Git repository Service Test pyramid kind: HelmRelease version: XYZ … kind: HelmRelease version: XYZ … Defines testing strategy apply/delete Defines cluster state Reconciles Git commit/push GitOps git commit/push git commit/push Monitors for new chart versions Build platform Deployment platform Github Actions work fl ow: • Template • Custom Actions • GitOps tooling • Kubernetes cluster
64. Summary… Team topologies requires Loosely design-time coupled architecture Fast, automated deployment pipeline The modular monolith works well for smaller applications/ organizations A successful application can outgrow the monolithic architecture The microservice architecture enables team topologies at scale: Team autonomy Reduced cognitive load Fast feedback
65. …Summary: microservices platforms needed
66. @crichardson @crichardson chris@chrisrichardson.net http://adopt.microservices.io Questions?