You Don't Need Microservices (Unless You Do)

Let's be honest: for 90% of the startups in Oslo, a well-structured monolith is fine. But you aren't here for fine. You're here because your engineering team has scaled past the point where a single deployment pipeline is sustainable, or your domain complexity has turned your codebase into a ball of mud. I've spent the last decade debugging distributed systems across Europe, and if there is one truth, it is this: Microservices turn compile-time errors into runtime errors.

When you split a monolith, you trade memory calls (nanoseconds) for network calls (milliseconds). If your infrastructure isn't rock solid, that latency difference kills your user experience. This guide covers the architectural patterns that keep systems resilient, assuming you are deploying on a stack that existed by mid-2025.

The Ambassador Pattern: Stop Exposing Everything

Security teams hate microservices because the attack surface area explodes. You cannot have 50 services listening on public ports. You need an Ambassador (or API Gateway) that handles ingress, SSL termination, and rate limiting. It acts as the single entry point.

In a Kubernetes environment (standard by now), you might use an Ingress Controller like NGINX or a more modern gateway like Envoy. Here is a practical example of offloading SSL and enforcing HTTP/2 at the edge using NGINX configuration, which is still the workhorse of the web.

http {
    upstream backend_services {
        server service-a:8080;
        server service-b:8080;
        keepalive 32;
    }

    server {
        listen 443 ssl http2;
        server_name api.coolvds-client.no;

        # SSL Optimization for low latency handshakes
        ssl_session_cache shared:SSL:10m;
        ssl_session_timeout 10m;
        ssl_buffer_size 4k;

        location / {
            proxy_pass http://backend_services;
            proxy_http_version 1.1;
            proxy_set_header Connection "";
            
            # Critical for tracing
            proxy_set_header X-Request-ID $request_id;
        }
    }
}

Pro Tip: Never deploy an API gateway without request tracing. In the example above, X-Request-ID is your lifeline when a customer complains that "the app is slow" and you have to find out which of your 12 services is the bottleneck.

Circuit Breaker: Fail Fast, Recover Faster

The most common outage cause isn't a hard crash; it's a slow service. If Service A calls Service B, and Service B takes 30 seconds to timeout, Service A's threads get blocked. Eventually, Service A runs out of resources and dies. The cascade begins.

We solve this with the Circuit Breaker pattern. If a service fails repeatedly, stop calling it. Return a default response or an error immediately. If you are using a service mesh like Istio (common in 2025), you define this in a DestinationRule.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: payment-service-circuit-breaker
spec:
  host: payment-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 1024
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 1s
      baseEjectionTime: 30s
      maxEjectionPercent: 100

This configuration ejects the payment-service from the load balancing pool for 30 seconds if it returns five consecutive 500 errors. This gives the failing pod time to recover (or restart) without taking down the entire checkout flow.

The Infrastructure Reality Check: KVM vs. Containers

Here is where many architects fail. They design beautiful distributed systems but deploy them on "noisy neighbor" container environments. In a microservices architecture, tail latency (the slowest 1% of requests) defines your user experience. If one microservice waits for CPU time because your provider oversold the host, the entire chain slows down.

At CoolVDS, we specifically utilize KVM (Kernel-based Virtual Machine) hardware virtualization. Unlike simple containers (LXC/OpenVZ) where the kernel is shared, KVM provides stronger isolation. When you run a database or a heavy computation service on CoolVDS, your allocated CPU cycles are yours. This is non-negotiable for high-throughput messaging systems like Kafka or RabbitMQ.

Storage I/O: The Silent Killer

Stateless services are easy. Stateful services—your databases—are where the pain lives. Distributed databases (like CockroachDB or Cassandra) rely heavily on disk I/O coordination. If your VPS provider throttles your IOPS, your cluster initiates leader elections unnecessarily.

We use NVMe storage arrays. Let's look at a quick fio benchmark you should run on any potential host to verify they aren't lying about "SSD" speeds. This command simulates a random read/write workload common in databases.

fio --name=random_rw_test \
    --ioengine=libaio \
    --rw=randrw \
    --bs=4k \
    --numjobs=4 \
    --size=1G \
    --runtime=60 \
    --time_based \
    --group_reporting

If you see IOPS below 10,000 on a modern "performance" plan, move on. Your microservices will choke on I/O wait times.

Data Sovereignty and The Norwegian Context

Since the Schrems II ruling and subsequent tightening of GDPR interpretations by the Norwegian Datatilsynet, where your data physically sits is a legal liability. Hosting on US-owned hyper-scalers (even in EU regions) involves complex Transfer Impact Assessments (TIAs).

Hosting with a provider like CoolVDS, which operates directly out of Oslo with strict Norwegian jurisdiction, simplifies compliance. Furthermore, if your user base is in Norway, physics is on your side. Peering through NIX (Norwegian Internet Exchange) ensures that traffic between your users and your API often stays within the country, dropping latency from 30ms (routing via Frankfurt) to sub-5ms.

The Sidecar Pattern: decoupling Logic from Network

In 2025, we don't write retry logic inside our Python or Go code anymore. We delegate it to a Sidecar proxy. This keeps your business logic clean. However, sidecars consume resources. If you deploy 50 services, you have 50 sidecars.

Resource limits in Kubernetes become critical here. If you don't set them, a memory leak in a sidecar can OOM (Out of Memory) kill the node.

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi

Applying these limits ensures that your infrastructure remains predictable. We see too many developers leave these blank, leading to the "Noisy Neighbor" effect inside their own cluster.

Final Thoughts

Microservices are not a silver bullet; they are a complexity exchange. You trade code complexity for operational complexity. To succeed, you need observability, strict patterns like Circuit Breakers, and infrastructure that doesn't flinch under load.

Your architecture deserves a foundation that respects physics and privacy. Don't let slow I/O or unstable peering kill your SLA. Deploy a KVM-based CoolVDS instance in Oslo today and benchmark the difference yourself.