A team ships one Django application. Checkout, search, user accounts, email, and reporting all live in one codebase behind one deploy. It works well for a year. Then a flash sale sends search traffic through the roof, the process runs out of memory, and checkout goes down with it, because both share the same server. That shared-fate moment is where most teams first ask about microservices.
Microservices split one application into small, independent services that each own one job and talk over the network. Done well, search can scale on its own and a crash in reporting never touches payments. Done badly, you trade one messy codebase for a dozen of them plus a network in between. The Python question is really two questions: should you split at all, and if so, how.
When microservices make sense, and when a monolith is smarter
Microservices earn their complexity in a few clear situations:
- Different parts of the system need to scale independently, such as heavy search next to light billing.
- Several teams need to deploy without waiting on each other.
- Parts have genuinely different needs, like a CPU-bound ML service beside an I/O-bound API.
- You want to isolate failure so one struggling feature cannot take down the rest.
For most early products, a well-structured monolith is the smarter start. It is simpler to build, test, and deploy, and you can carve services out later once the seams are obvious. Splitting too early, before you know where the real boundaries are, is one of the most expensive mistakes in backend work. A modular monolith, with clean internal boundaries between modules, often captures most of the organizational benefit without the network hops, the extra deployments, or the distributed debugging. If you are choosing a runtime as much as an architecture, the trade-offs in Python vs. Node for backend development are worth reading before you commit.
Python frameworks for microservices
Three tools cover most Python services:
- FastAPI is the common default now. It is async-first, fast, and generates OpenAPI docs automatically, which matters when services call each other.
- Flask is minimal and battle-tested, with a huge ecosystem. A solid choice for small synchronous services or teams that already know it.
- Nameko is built specifically for microservices, with RPC and messaging patterns baked in, useful when services communicate over a message broker rather than HTTP.
For heavier internal traffic between services, some teams reach for gRPC, which is faster and strongly typed but harder to inspect than plain JSON over HTTP. For public-facing HTTP services, the choice usually comes down to FastAPI versus Flask, which we cover in FastAPI vs. Flask for microservices. Whichever you pick, each service is essentially a small, well-defined API, so the same discipline from building scalable REST APIs with Python applies to every one of them.
Boundaries, async, and how services talk
The hardest part of microservices is not code, it is drawing the lines. Split by business capability, not by technical layer. “Orders,” “payments,” and “notifications” are good boundaries; “the database service” and “the API service” are not, because they force every feature to touch several services at once. A quick test for a boundary: if a single common change, like adding a field to an order, forces you to edit three services at once, the line is in the wrong place.
Once split, services communicate two ways. Synchronous calls over HTTP or gRPC are simple and immediate but create tight coupling; if payments is slow, everything waiting on it is slow. Asynchronous messaging through a broker like RabbitMQ or Kafka lets a service drop an event and move on, and others react in their own time. Most real systems use both. An API gateway sits in front, giving clients one entry point while it routes requests to the right service and handles authentication and rate limiting in one place.
Python’s async support, meaning async/await and frameworks like FastAPI built around it, matters here. A service that spends most of its time waiting on other services benefits from handling many requests concurrently instead of blocking on each one. In practice, one FastAPI worker can hold hundreds of in-flight requests that are all waiting on a database or a downstream call, where a synchronous worker would need a separate thread or process for each.
A realistic Python microservices stack
A typical setup looks like this: FastAPI for each HTTP service, PostgreSQL with one schema per service, RabbitMQ or Kafka for events, an API gateway such as Kong or Traefik in front, Docker for packaging, Kubernetes for orchestration, and a logging-plus-tracing stack for visibility. You do not need all of it on day one. Start with two or three services, plain HTTP, and Docker Compose, then add messaging and orchestration when the load and the team size actually call for it.
Containers and observability
Each service ships in its own container. Docker gives every service the same environment from a developer laptop to production, and we walk through it in containerizing a Python microservice with Docker. Once you have more than a few, an orchestrator like Kubernetes handles deployment, scaling, and restarts.
Observability is not optional with microservices, it is the price of admission. When one request crosses six services, you need centralized logging, metrics, and distributed tracing to see where it slowed down or failed. Setting up that pipeline, along with CI/CD and orchestration, is squarely cloud and DevOps work, and skipping it is how teams end up flying blind. Some shops also mix runtimes here, running a few Node.js services alongside Python where the event-driven model fits a particular job better.
Common pitfalls
- Splitting too early. A monolith you understand beats microservices you do not.
- A shared database. If every service reads the same tables, you have a distributed monolith with all the pain and none of the independence.
- Ignoring failure. Networks drop calls. Every remote call needs timeouts, retries, and a plan for when the other service is down.
- No API versioning. Change a service’s contract without versioning and you break its callers silently.
There is also a people dimension. Microservices distribute not just code but ownership, so they work best when each service has a clear team or owner responsible for it. Without that, services drift, shared contracts go unmaintained, and the architecture slowly rots into something harder to change than the monolith it replaced.
Handled well, microservices give a growing product room to scale by team and by load. Handled carelessly, they add latency and operational cost for no gain. The deciding factor is rarely the framework, it is the design and the operational maturity behind it. That balance is what our custom software and Python development teams weigh on every build.
Thinking about splitting a monolith or starting a new system in services? We will help you decide what to split, what to leave alone, and how to run it without drowning in ops. Explore our Python development services or start a conversation about your architecture.