2026-10-16 –, Principal
Microservices group by domain. Micro-monoliths group by team. These are different mental models — and the second one solves the real problem for most companies.
The most common way to divide systems follows the domain: payments here, users there, notifications somewhere else. What that question ignores is: who owns each piece?
The micro-monolith starts from a different premise: the right boundary is the team boundary, not the semantic one. If two different teams develop features in the same service, you have an organizational problem that no architecture will solve. If a team has clear ownership over a service — even if it spans concepts from different domains — you have real autonomy.
Pyramid is the Python framework that doesn't make decisions for you. No mandatory ORM, no imposed folder structure, no magic. That makes it the natural choice for an architecture where you want to be explicit about boundaries — not the framework.
In this talk I share one way of thinking about organizing services around teams (not domains), explicit public contracts with Pyramid, and the practical decision of where a new feature belongs.
You'll leave with a mental model that challenges the mainstream and a concrete Python structure to apply the next day.
Participants should be comfortable writing Python at an intermediate level — functions, classes, modules, and basic web concepts (HTTP, request/response). No prior knowledge of Pyramid, microservices, or domain-driven design is required. Architectural concepts around team structure and service boundaries will be introduced during the talk. The target audience is developers who have worked on a Python web project before and are starting to think about how to structure systems as teams and codebases grow.
What can participants expect to learn from your activity?:Participants will leave with a concrete mental model for thinking about service boundaries — one that prioritizes team ownership over semantic grouping. They will see a practical Python structure built with Pyramid that they can use as a reference when designing or refactoring their own services. They will also gain a framework for making the recurring decision of where a new feature belongs: not based on domain purity, but on who is responsible for it. Finally, they will be exposed to a different way of thinking about Python web frameworks — one where explicitness and simplicity are features, not limitations.
Choose one or more areas where this proposal fits.: Web Development, Software Architecture, People
CTO and co-founder of Robbin, a fintech platform built on the architecture in this talk. Nearly 30 years of software experience, focused on pragmatic system design.