TECHNOLOGIES

Microservices

An architecture that splits an application into many small, independently deployable services, which buys you scaling and team independence at the price of real distributed-systems complexity.

Last reviewed: 2026-06-02 byKevin Riedl wiki β†—

Microservices means breaking an application into many small services, each owning one piece of the business and each deployable on its own. Instead of one program where everything runs in the same process, you get a fleet of services talking to each other over the network. The promise is real: teams can ship independently, you can scale only the parts that need it, and one service can fail without taking the whole system down.

The cost is also real, and it is usually underestimated. The moment your function calls become network calls, you have a distributed system, and distributed systems are hard. You inherit network failures, latency, data spread across many databases with no easy transactions, versioning between services, and the operational burden of running, monitoring, and debugging many moving parts instead of one. A bug that used to be a stack trace is now a trace across five services and three queues.

The honest stance: most startups should start with a monolith. A well-structured single application is faster to build, far easier to debug, and perfectly capable of carrying you to real revenue. You split into microservices when you have a concrete reason, a team large enough that one codebase is a bottleneck, or a workload that genuinely needs independent scaling, not because microservices are the fashionable answer. Premature microservices are how small teams turn one hard problem into ten.

Polity ran on seven microservices, and that was the right call for its scale and team structure. That is the point: the architecture should follow the problem and the org chart, not a conference talk. Pick the boundaries where they actually reduce coupling, and accept that every boundary you draw is a network call you now have to defend.

// FAQ

FAQs

FAQs

An architecture that splits an application into many small, independently deployable services, each owning one piece of the business and talking to the others over the network. It buys independent deployment and targeted scaling at the cost of distributed-systems complexity.
A monolith is one application in one process, faster to build and far easier to debug. Microservices are many networked services, better for large teams and independent scaling but much harder to operate. Most startups should start with a monolith and split only when there is a concrete reason.
When a single codebase has become a real bottleneck for your team, or when part of the workload genuinely needs to scale independently. Not because it is fashionable. Premature microservices turn one hard problem into ten and slow a small team to a crawl.