Scaling discussions tend to begin with microservices and Kubernetes. In practice, the first thing that breaks under real traffic is almost always the database, and it usually breaks because of a query someone wrote in month two without thinking about it much. Architecture matters, but it matters later than most teams assume and in a different order than most articles suggest.
The Order Things Actually Break
- First: Unindexed queries and N+1 patterns. Fine at a thousand rows, fatal at a million.
- Second: Synchronous work in the request path. Sending email or generating a PDF inline works until it does not.
- Third: Session and connection state that assumes one server.
- Fourth: Anything that loads an entire table into memory to compute a number.
- Much later: The things people worry about first, such as needing to split into services.
Measure Before You Rearchitect
The instinct when a system feels slow is to reach for a bigger architecture. The discipline is to find out what is actually slow first. Application performance monitoring will usually show that a small number of endpoints account for most of the pain, and that within those endpoints, a small number of queries account for most of the time. Fixing those is hours of work. Rearchitecting is months.
We have repeatedly been brought in to help a team migrate to microservices and instead added four indexes, moved two jobs to a queue, and returned the system to comfortable headroom. That is not always the answer, but it is the answer often enough that it should always be the first investigation.
Caching Is Powerful and Genuinely Dangerous
Caching is the highest-leverage change available to most applications, and also the most reliable source of subtle, infuriating bugs. The rule worth holding to is that a cache must have exactly one owner and an explicit invalidation strategy written down before it ships. Caches that accumulate organically across a codebase produce systems where nobody can explain why a user is seeing stale data.
Start with the layers that are hardest to get wrong: a CDN for static assets, HTTP caching for public responses, and a shared cache for expensive computed values with a conservative time-to-live. Reach for per-object caching only when you have measured that you need it.
Move Work Out of the Request
Anything a user does not need to see the result of immediately should not happen while they wait. Email, notifications, report generation, third-party synchronisation, image processing: all of it belongs in a background queue. This single change frequently transforms perceived performance more than any infrastructure upgrade, and it has the additional benefit of making failures retryable rather than user-visible.
The Database Is the Hard Part
Application servers scale horizontally with relative ease. Databases do not. Read replicas handle read-heavy load well and are usually the correct first move. Sharding is the point at which complexity increases sharply, and it should be deferred as long as is responsible, because it is difficult to reverse and it complicates every subsequent query.
Before sharding, exhaust the cheaper options: better indexes, archiving cold data out of hot tables, connection pooling, and moving analytical queries off the transactional database entirely. Many teams that believed they needed to shard simply needed to stop running reports against production.
Microservices Solve an Organisational Problem
Splitting a system into services is primarily a solution to teams blocking each other, not to a system being slow. If you have fewer than roughly twenty engineers, a well-structured monolith will almost certainly serve you better, and you will spend the time you save on product rather than on distributed tracing. The costs of a service boundary are real and permanent: network calls fail, transactions no longer span the boundary, and debugging spans multiple systems.
The pragmatic middle path is a modular monolith with clean internal boundaries. If a module later needs to become a service, well-drawn boundaries make that extraction tractable. Poorly drawn ones make it impossible regardless of your architecture diagram.
KnC Future Tech has helped teams scale products from early traction to substantial production load. The recurring lesson is that scaling well is mostly about doing ordinary things carefully and resisting the urge to solve problems you have not measured.
Interested in building something similar?
KnC Future Tech builds web, mobile, and custom software for teams worldwide. Let’s talk about your idea.
Book a Free Discovery Call
