Microservices Without the Migraine: Core Patterns for High-Performance Infrastructure

Let’s be honest for a second. Everyone is tearing apart their perfectly functional monoliths because Netflix and Uber told them to. But here is the brutal truth they don't mention in the conference slides: Microservices turn memory calls into network calls.

In your monolithic Magento or Drupal setup, function A calls function B in nanoseconds. In a distributed architecture, Service A calls Service B over the network. If your underlying infrastructure has jitter, packet loss, or "noisy neighbor" CPU steal, your application doesn't just get slow. It cascades into failure.

I’ve spent the last week debugging a timeout issue for a client in Oslo. The culprit wasn't code. It was a cheap VPS provider overloading their host nodes. Today, we are going to look at the architectural patterns that mitigate this risk, utilizing tools available right now in 2016, and why hardware choices like NVMe and KVM are not optional luxuries anymore.

1. The API Gateway Pattern (Nginx)

Do not expose your microservices directly to the public internet. Just don't. It’s a security nightmare and makes SSL termination a headache.

The standard pattern for 2016 is the API Gateway. We use Nginx as the entry point. It handles the SSL handshake, logs the request, and routes it to the correct internal service (usually running in a Docker container).

Here is a battle-tested configuration we use at CoolVDS for high-throughput frontends. Notice the buffer adjustments; standard configs will choke on large JSON payloads.

http {
    upstream auth_service {
        server 10.10.0.5:8080;
        keepalive 64;
    }

    upstream inventory_service {
        server 10.10.0.6:9000;
        keepalive 64;
    }

    server {
        listen 443 ssl http2;
        server_name api.yoursite.no;

        ssl_certificate /etc/nginx/ssl/live.crt;
        ssl_certificate_key /etc/nginx/ssl/live.key;

        location /auth/ {
            proxy_pass http://auth_service;
            proxy_http_version 1.1;
            proxy_set_header Connection "";
            proxy_set_header X-Real-IP $remote_addr;
        }

        location /inventory/ {
            proxy_pass http://inventory_service;
            # Crucial for performance
            proxy_buffer_size 128k;
            proxy_buffers 4 256k;
            proxy_busy_buffers_size 256k;
        }
    }
}

Pro Tip: Enable HTTP/2. It was finalized last year (2015) and Nginx 1.9.5+ supports it. It significantly reduces latency for clients on mobile networks connecting to servers in Norway.

2. Service Discovery: No More Hardcoded IPs

If you are managing your IPs in a spreadsheet, stop. In a dynamic environment where containers die and respawn, IP addresses change. You need Service Discovery.

We are seeing a massive shift towards Consul (by HashiCorp) this year. Unlike Zookeeper, which is a beast to manage, Consul is a binary you can drop anywhere. It handles DNS resolution for your services.

Instead of pointing your app to 192.168.1.50, you point it to inventory.service.consul.

Deploying a Consul Agent

Run this on your CoolVDS instances to join them to the cluster. We use the private network interface (eth1) to keep chatter off the public internet.

# Start the Consul agent in server mode (bootstrap expect 3 for quorum)
./consul agent -server -bootstrap-expect=3 \
    -data-dir=/tmp/consul -node=agent-one -bind=10.0.0.1 \
    -config-dir=/etc/consul.d

Then, register a service by dropping a JSON file in /etc/consul.d/web.json:

{
  "service": {
    "name": "web-worker",
    "tags": ["production", "v1"],
    "port": 80,
    "check": {
      "script": "curl localhost:80 >/dev/null 2>&1",
      "interval": "10s"
    }
  }
}

If the check fails, Consul removes the node from DNS. Your load balancer automatically stops sending traffic to the dead node. This is self-healing infrastructure.

3. The Database per Service Dilemma

This is the hardest pill to swallow. In a monolith, you have one giant MySQL instance. In microservices, the strict rule is Database per Service.

Why? Because if the "Billing Service" locks a table, the "User Profile Service" shouldn't freeze. However, running 10 separate MySQL instances requires serious I/O performance.

This is where hardware realities hit you. Standard spinning rust (HDD) or even SATA SSDs struggle with the random I/O of ten concurrent databases.

At CoolVDS, we enforce KVM virtualization. Unlike OpenVZ, KVM provides true hardware isolation. Your databases won't slow down just because a neighbor is compiling a kernel. Combine that with our local NVMe storage, and you have the throughput required to run distributed data layers.

4. Local Context: Data Sovereignty & Latency

We are writing this in April 2016. Just yesterday, the EU Parliament formally approved the General Data Protection Regulation (GDPR). It’s coming. The Safe Harbor framework was invalidated last year. If you are serving Norwegian customers, storing data on US-controlled servers is becoming a legal minefield.

Hosting locally isn't just about compliance; it's about physics. Light speed is finite.

• Ping from Oslo to Frankfurt: ~25-30ms
• Ping from Oslo to CoolVDS (Oslo): ~2ms

In a microservices architecture, a single user request might trigger 10 internal service calls. If those calls go across borders, you are adding 300ms of pure network lag. Keep your compute where your users are.

Summary: The Infrastructure Matters

Microservices resolve organizational scaling issues but introduce operational complexity. You trade code complexity for infrastructure complexity.

1. Use Nginx as a gatekeeper.
2. Use Consul to track your fleet.
3. Use Docker (v1.10+) for consistent environments.
4. Host on KVM/NVMe to prevent I/O bottlenecks.

Don't build a Ferrari engine and put it in a tractor. If you are architecting for the future, you need infrastructure that respects the demands of distributed systems. Test your architecture on a platform designed for high I/O and low latency.

Need to benchmark your stack? Deploy a CoolVDS instance in Oslo. We offer full root access and the raw performance your microservices demand.