Most tutorials tell you to start with a monolith. Here's why InternFlow went the other way — and what I learned from it.
When I started building InternFlow, I knew it wouldn't be just another CRUD application. The platform needed to handle job crawling, AI-powered repository analysis, resume generation, authentication, and multiple background processes — all running concurrently.
The obvious first instinct was to put everything inside one FastAPI application. Easier to build, easier to run locally, easier to reason about.
But I kept running into the same problem: each feature had wildly different resource requirements.
The resource mismatch problem
- Job Crawler — Network I/O bound, runs on a schedule
- AI Service — CPU and memory heavy, unpredictable duration
- Web API — Latency sensitive, users expect immediate responses
- RAG Service — FAISS indexes + embedding models loaded in memory
If all of these lived in one process, a single heavy AI request could block user-facing API responses. The job crawler running on a schedule would compete for the same thread pool as the REST endpoints. Debugging which part of the monolith was causing the slowdown would become a nightmare.
Running different workloads inside one process means the worst-performing one defines your entire system's reliability.
The architecture I settled on
┌─────────────────────┐
│ Next.js Frontend │
└──────────┬──────────┘
│ HTTP
┌──────────▼──────────┐
│ FastAPI API Service │
└──┬──────────────┬───┘
│ Docker │ internal network
┌────────▼───┐ ┌──────▼──────┐ ┌───────────┐
│ AI Service │ │ RAG Service │ │ Crawler │
└────────────┘ └─────────────┘ └───────────┘
│ │
┌────────▼──────────────▼──────────┐
│ PostgreSQL │ Redis │
└─────────────────────────────────┘
Docker Compose became the glue holding everything together. Each service has its own Dockerfile, its own environment variables, and its own health checks. They communicate over a shared internal network, but are completely isolated from each other's failures.
Monolith vs microservices for this project
| Single FastAPI App | Microservices (chosen) |
|---|---|
| Heavy AI task slows all API responses | AI service is isolated — API stays fast |
| Crawler competes with user requests | Crawler runs on its own schedule |
| One crash takes everything down | Service restarts don't affect others |
| Hard to find the slow component | Per-service logs make debugging fast |
| ✅ Simpler local dev setup | ❌ Docker Compose adds initial overhead |
The trade-off was real: the initial setup took longer. Writing Docker configs, managing inter-service communication, and dealing with network issues added friction in the first week. But every hour spent on that setup saved multiple hours later when debugging and scaling.
What I'd tell someone starting a similar project
If your project has genuinely different resource profiles across features — network-heavy, compute-heavy, latency-sensitive — separate them early. The cost of splitting a monolith later is much higher than the cost of Docker Compose configuration upfront.
If you're building a simple CRUD app with one background job, a monolith is probably the right call.
InternFlow wasn't that kind of project.
Docker Compose isn't just a deployment tool — it's an architectural decision that forces you to think about service boundaries before you have to.
In Part 2, I'll explain how I designed the AI pipeline that powers repository analysis and resume generation — including why I chose RAG over direct LLM API calls.
I'm building InternFlow — an AI code review and resume generation platform for B.Tech and engineering students. Connect your GitHub, get line-level code reviews on every commit, and turn your real work into ATS-ready resume bullets.
→ Try it free at intern-flow.in