Microservices got a bad rap, mostly because people copy the FAANG version. Here is the much smaller, much saner version we run — and the parts that actually matter when your team fits in one room.

Every microservices article on the internet is written by someone who either runs Netflix or really wants you to think they do. The version most of us actually need is much smaller, much saner, and almost embarrassing to admit out loud.

Most teams do not need microservices. Some teams do. And almost no team needs the version they read about on Hacker News.

The version we actually run

At XYZ Solutions we run a microservices system for an agentic AI content platform. Here is the embarrassingly small version of it.

gateway        — public HTTP, auth, routing
agents-api     — orchestrates the agent runs
agents-runner  — does the heavy LLM stuff
writer-svc     — drafts and rewrites
review-svc     — critiques and edits
storage-svc    — Postgres + S3 wrapper
queue          — RabbitMQ
infra          — Docker + Coolify on a couple of VPSes

That is the whole map. No service mesh. No Kubernetes. No 100-page README. The team is small, the services are small, and the boundaries are picked to match how the work actually flows — not how a textbook says they should.

What earned its keep

1. Queues, not chains

Every long-running step goes through RabbitMQ. The agents-api does not call the writer-svc directly; it drops a job on a queue, the writer-svc picks it up. If the writer crashes mid-job, the message comes back. If we need to scale writing, we add another writer. The rest of the system does not need to know.

2. gRPC for the boring stuff

Inside the cluster, services talk over gRPC. Strict contracts mean breaking changes scream at us at build time, not at 3am. Outside, the gateway still speaks REST, because nobody wants to debug Protobuf in a browser.

3. Coolify as the platform team

We deploy with Git pushes. SSL, env vars, restarts, logs — Coolify handles the boring parts so I can spend my brain on the system, not on YAML.

What we skipped, on purpose

No Kubernetes. No service mesh. No event store. No CQRS. No saga framework. No bespoke message envelope schema. Every one of these is a fine tool — but every one of them is also a tax, and we cannot afford the tax yet.

The actual rule

Split a service when keeping it together hurts more than splitting it will. Not before.

That is most of it. The rest is just paying attention to the seams. Real posts go up here as I find time, but if the agents AI platform is the thing you want to read about, that one is coming next.