Designing NestJS microservices that scale
Six microservices walk into a bar. The bar is a message queue, and somehow it's already down.
1. Start with one service and lie to yourself
Every great microservices architecture begins as a monolith that someone swore would 'stay small.' It did not stay small. It never stays small. You added one little feature, then auth, then notifications, and now your 'small' service has the body count of a soap opera.
My rule: don't split a service until it physically hurts to deploy. If two features still happily share a database and never argue, they're not two services — they're roommates. Leave them be.
2. The database is the real boss
People think the hard part of microservices is the services. It's not. It's the data. The moment Service A needs Service B's table, you have invented a distributed monolith — all the latency of microservices, all the coupling of a monolith, and a pager that goes off at 3 a.m. out of spite.
I give each service its own Postgres schema and a strict 'no peeking' policy. If you want my data, you ask me nicely over an API like a civilized process.
3. RBAC, or: who let the intern delete prod
Role-based access control is the seatbelt nobody appreciates until the windshield. NestJS guards make it almost pleasant — one decorator, and suddenly the intern can look but not touch.
Wrap it once, test it twice, and never trust a request just because it showed up wearing a valid-looking token. Tokens lie. Tokens are the cats of the internet.
