Does your app need microservices and Kubernetes? Usually not yet, and how you'll know

Do you need microservices? Probably not yet. In our view, most business apps run well as one application on one database, deployed simply. Microservices, Kubernetes and a sharded database solve the problems of large teams and very large load. Added early, they bring moving parts and specialist upkeep before they bring any benefit.

We build web applications as part of our custom software development work, and we would start most of them as one application. This is architecture guidance, not a universal rule. What fits depends on your data, your load and who will run the system.

Start with one application and one database

In our view, one application on one database is the sound default for a new app, and for most apps that serve one business. It has the fewest parts to deploy, watch and repair. Each heavier piece below answers a specific problem.

• Monolith. One application, built and released as a single unit, usually with one database.
• Container. A program packaged with everything it needs and run in isolation, so it behaves the same on any machine. Docker's documentation calls containers isolated processes for each of your app's components.
• Orchestrator. Software that starts, restarts and spreads containers across several servers. Kubernetes is one. Its documentation describes it as a platform for managing containerised workloads and services.
• Microservices. An app split into small services, each with its own code and data. Microsoft describes them as components that a single small team of developers can write and maintain.
• Read replica. A copy of the database that follows the main one and answers read-only queries. PostgreSQL calls a copy that serves reads a hot standby.
• Shard. One slice of the data, kept in a separate database, usually on its own server. In Microsoft's words, each shard has the same schema but contains its own distinct subset of the data.

Caching, which appears in the tables too, means keeping the answer to a frequent request in fast memory, so the database is not asked every time.

Do you need microservices, Kubernetes or sharding?

Your app needs a heavier piece only when a signal you can measure points to it. Find the rows that are true for you today.

What each piece costs you to run

Every piece adds something to deploy, monitor, update and repair.

Microservices. Microsoft's architecture guide is plain about the trade. It says a microservices application has more moving parts than the equivalent monolithic application. Because each service keeps its own data, consistency across services can be a challenge. The guide says success requires "a mature DevOps culture": the habits and tools to release and monitor software often.

Kubernetes. Its documentation says it provides a framework to run distributed systems resiliently: restarts, load balancing and controlled rollouts. It does not build your application or dictate logging, monitoring or alerting, so you choose and run those too. A cluster has a control plane and one or more worker nodes, and someone has to look after both.

Sharding. Microsoft's sharding pattern says it introduces substantial and permanent complexity into your data architecture, for the system's lifetime. Monitoring, backups and changes to the database's structure must then cover every shard.

The Monolith First essay on martinfowler.com makes a related point. It notes that "almost all the successful microservice stories have started with a monolith that got too big and was broken up".

Signs you have outgrown one app and one database

You have outgrown the simple setup when a measurement shows a limit that simpler fixes did not remove. These signs come from the sources' own descriptions of when each pattern fits; none of them is a number of users.

• The database has hit a limit you can't scale past. Microsoft suggests sharding when the data outgrows one database and no larger server fixes it, or when the load exceeds what a single instance can sustain.
• Writes, not reads, are the bottleneck. The same page says read replicas and caching can offload read traffic. Sharding is for when write load is also high.
• One table has grown very large. PostgreSQL's guidance is that partitioning, splitting one large table into smaller pieces, is normally worthwhile only when a table would otherwise be very large. Its rule of thumb is a table bigger than the server's memory. Partitioning still runs inside one database.
• Teams are getting in each other's way. Microsoft lists small, focused teams and independent releases as benefits of microservices. With one team, there is nobody to unblock.
• One part needs to scale on its own. The same guide notes that services can be scaled independently. That helps only when one part's load differs clearly from the rest.

Microsoft also lists when sharding might not be suitable: when your data and throughput fit within a single database, even with projected growth. In our view, that describes most business apps today.

A common order to grow in

A common path is one step at a time, simplest first, measuring before each step. It is not a universal ladder. Consistency, availability and who will run each piece decide the order for your app.

An app that must stay up through a server failure may need a standby copy of the database for that reason alone. Data that must never be stale, such as stock levels or balances, may rule out some caching and replica reads. A piece nobody on your side can run is a risk, whatever its place in the list.

1. MeasureFind out what is actually slow. In PostgreSQL, the EXPLAIN command shows how a query will run. The pg_stat_statements module, once switched on, tracks statistics for every query the server runs.
2. Fix slow queries and add cachingFix what the measurement shows, such as a missing index or the same query repeated for every item in a list. Cache answers that are asked for often and change rarely.
3. Move to a larger serverMicrosoft notes you can scale vertically, adding processing power, memory and disk, to postpone the limits of one server for a time.
4. Add a read replicaA replica takes read-only queries off the main database. PostgreSQL's documentation says read-only database servers can be combined relatively easily, while servers that also write are much harder to combine.
5. Split out one partIf one part has its own team or its own load, move only that part into a separate service. Keep the rest as one application.
6. Shard lastShard only when the data or the writes are beyond one server after every step above. Partitioning a table within one database comes first, and needs no extra servers.

Infrastructure follows the same rule as scope: build for the users you have, and write down what waits.

If your app arrived with all of this already

Then the first question is what each piece is doing for you today. An app built quickly, sometimes with AI coding tools, can arrive with containers, an orchestrator and several services in place. That is not wrong in itself, but it means more to run.

A review answers this before anyone changes anything. Our guide on how to review an app built with AI coding tools covers what that review looks at. Whoever built it, make sure the code and accounts are in your company's name; what to do when your developer left lists them.

Questions to ask before you accept the architecture

Ask these of whoever proposes the setup, whether that is a freelancer, a development company or your own team. Good answers are specific and point to a measurement.

If you're still choosing what to build, read website, web app or mobile app. If a ready-made product might do, read off-the-shelf, low-code or custom software.

Next step: send us a short note on what the app does, who uses it, and the setup you were given or quoted. We reply within 24 hours, with a few questions or a time for a call.

Reviewed and edited by Online Scope before publishing. Something out of date? Tell us at info@onlinescope.in. How we write the Blog.