Microservices vs Monolith: When to Split Your Architecture

A developer at CitizenApp rebuilt the backend twice, first splitting into microservices and then merging back into a monolith after debugging distributed tracing for six months. The post provides a decision framework for when to split architecture, advising to start monolithic and split only when specific problems like different deployment frequencies, resource contention, technology constraints, or performance profiles arise. The developer notes that microservices can increase infrastructure costs from $50/month for a monolith to over $10K/month for production microservices.

I've rebuilt CitizenApp's backend twice. Once I split it into microservices because "that's what production systems do." I was wrong. We spent 6 months debugging distributed tracing logs instead of shipping features. Then we merged back into a monolith, and velocity tripled. This post isn't romantic. It's a decision framework for when distributed systems actually pay off—and when they're just complexity theater. Start monolithic. Every successful SaaS I know—Stripe, GitHub, Figma—began as a single codebase. This isn't laziness; it's pragmatism. A monolith with Astro + FastAPI gives you: For CitizenApp's first 18 months, we ran everything in a single FastAPI app on Render. 50K users. 9 AI features. One database. We shipped features faster than teams with "proper" microservices architecture. Cost matters too. A monolith on Render costs ~$50/month to start. Your first microservice architecture? You're looking at orchestration, service mesh tooling, monitoring agents, minimum 3-4x the infrastructure cost. Stop generalizing about "scale." Microservices solve specific problems: Your ML pipeline team needs to redeploy inference workers 20x daily. Your API team ships weekly. A monolith couples them. Split when: Different services have different deployment frequencies or risk profiles. python BAD: Monolith—one team blocks another class FastAPIApp: def get user self, user id: str : return db.query User .filter User.id == user id .first def generate embedding self, text: str : If this crashes, entire API goes down return claude client.create embedding text GOOD: Separate services api/main.py @app.get "/users/{user id}" async def get user user id: str : return {"id": user id, "name": "John"} ml/embedding service.py @app.post "/embed" async def embed text text: str : Independent scaling, independent deploys return await claude client.create embedding text One feature consumes all database connections and starves the rest. A monolith makes this a crisis. Split when: You need to isolate resource usage for reliability. I watched CitizenApp's document processing eat 40 DB connections while user login requests queued. We extracted it: Dedicated PostgreSQL pool for background jobs background pool = create engine DATABASE URL, pool size=5, max overflow=10, pool pre ping=True Verify connections are alive Main API keeps its own pool api pool = create engine DATABASE URL, pool size=20, max overflow=20 This was a config fix , not a service split. Know the difference. Your team knows Python. A new requirement needs Node.js + WebSockets. You hire specialists who want to own their stack. Split when: Technology genuinely constrains your team, not ego. At CitizenApp, our real-time collaboration engine became a separate Node.js service. Python developers built the core product. Node developers owned the socket layer. Clear boundaries. Clear ownership. You're serving 100K concurrent WebSocket connections for real-time features. Your API serves REST requests with average 200ms response time. These have opposite optimization strategies. A shared codebase gets tangled. Split when: Different services optimize for different performance profiles. □ Different services deploy 5+ times per day independently? □ Resource contention causes production incidents monthly? □ You need different tech stacks that teams prefer to own? □ One service requires horizontal scaling others don't? □ Your database is a bottleneck not your app logic ? □ You have 50+ engineers who can't maintain coherent monolith? If you checked fewer than 3 boxes: stay monolithic. Monolith Render, 10K users : $50/month Basic microservices Kubernetes, observability : $2K+/month Production microservices service mesh, distributed tracing, on-call rotations : $10K+/month The last line item is often invisible. Microservices require: Most teams split too early because of vanity architecture. I've seen startups choose Kubernetes on day 1. "We want to scale." They're running 3 Docker containers. Kubernetes doesn't make you Netflix; shipping features does. What actually burned me: splitting CitizenApp's authentication into a separate service "for security." We added: The real cost of microservices is cognitive load. Every service boundary is a place to debug, secure, test, and monitor. You're paying that cost immediately. For CitizenApp, we stayed monolithic for 18 months, split the ML pipeline legitimate reason , and kept everything else together. The result: we shipped 9 AI features faster than competitors with "proper" distributed systems. Architectural purity is cheaper than shipped features.