Why I Chose Microservices for a Solo Project
Every sensible piece of advice says a solo developer should build a monolith. I read all of it, and then I built Yarplus as microservices anyway. This is the honest accounting of that decision — including the parts I got wrong.
The advice I deliberately ignored
The standard wisdom is correct: for one developer, a monolith is faster to build, easier to deploy, simpler to debug, and cheaper to run. Microservices introduce network calls, distributed failure, deployment complexity, and data-consistency headaches — all costs usually justified only when you have multiple teams that need to ship independently.
I had none of those reasons. So why did I do it?
The reasons that were actually good
1. The domains genuinely wanted to be separate
Yarplus had pieces with very different shapes: a payments service that has to be cautious, auditable, and rarely changed; a content/feed service that changes constantly and can tolerate looser guarantees; and auth that everything depends on. Keeping payments isolated from the part of the codebase I touch every day wasn't architecture astronautics — it was risk management. I didn't want a careless change to the feed to ever ship next to billing code.
2. Failure isolation
If the discovery feed falls over, payments and subscriptions should keep working. Drawing hard boundaries meant a problem in one area couldn't cascade into taking money flows down with it. For a product whose entire value proposition is "creators can reliably get paid," that isolation mattered.
3. I wanted to actually learn it
I'll be honest: part of the motivation was that this was a project to learn on. Reading about service boundaries, message passing, and eventual consistency is nothing like living with the consequences of your own boundary decisions. I learned more about distributed systems in a few months of maintaining this than in everything I'd read before.
You don't understand the cost of a network boundary until you've debugged a bug that only exists because of one.
What it actually cost
The bill came due quickly, and it was steeper than I expected.
- Operational overhead. Several services means several things to deploy, monitor, and keep alive. As one person, every additional moving part is a tax on the time I have to build features.
- Distributed debugging. A request that crosses three services is three times as hard to trace. I had to invest in logging and correlation IDs far earlier than a monolith would have forced me to.
- Data consistency. The moment your data lives in more than one service, "just use a transaction" stops being available. I spent real effort on patterns to keep state coherent across boundaries that a single database would have handled for free.
- I split things too early. Some boundaries I drew were guesses, and a few were wrong. Moving a responsibility from one service to another after the fact is far more painful than moving a module inside one codebase.
What I'd do differently
If I started Yarplus today, I'd reach for a modular monolith first: one deployable unit, but with strict internal module boundaries and no shared database tables across modules. That gives you most of the conceptual benefits — clear domains, enforced separation — without the operational tax. Then I'd extract a service only when a specific, measured pressure demanded it: payments needing an independent deploy cadence, or one component needing to scale separately.
That's the real lesson. Microservices weren't wrong because the idea is bad; they were premature. The right sequence is well-separated modules now, separate services later, and only when something concrete forces the split.
Would I take it back?
As a product decision, partly. As a learning decision, not for a second. Building it the "wrong" way taught me exactly why the conventional advice exists — and now when I say "start with a monolith," I'm not repeating a rule I read. I'm repeating one I paid for.