Skalierbare Infrastruktur planen

Dein Startup hat die ersten 100 Nutzer. Alles läuft. Dann erwähnt dich ein österreichischer Tech-Blog, und plötzlich kommen 5.000 Besucher gleichzeitig. Dein Server geht in die Knie, die App ist nicht erreichbar, und potenzielle Kunden sehen nur eine Fehlermeldung.

Das ist kein hypothetisches Szenario -- es passiert ständig. Die Frage ist nicht, ob dein Startup skalieren muss, sondern wann. Und wenn du nicht vorbereitet bist, verlierst du Kunden, Geld und Vertrauen.

In diesem Beitrag zeige ich dir, wie du deine Infrastruktur von Anfang an so planst, dass sie mit deinem Startup mitwachsen kann -- ohne dass du jetzt schon ein Vermögen investieren musst.

Skalierung verstehen

Vertikale Skalierung (Scale Up)

Du machst deinen Server grösser: mehr CPU, mehr RAM, mehr Speicher. Das ist der einfachste Ansatz -- aber er hat Grenzen.

Vorteile:

• Einfach umzusetzen
• Keine Änderungen an der Architektur nötig
• Schnell implementiert

Nachteile:

• Es gibt eine physische Obergrenze
• Single Point of Failure -- wenn der Server ausfällt, ist alles weg
• Kann teuer werden

Horizontale Skalierung (Scale Out)

Du fügest mehr Server hinzu und verteilst die Last. Das ist komplexer, aber deutlich leistungsfähiger.

Vorteile:

• Praktisch unbegrenzt skalierbar
• Redundanz -- ein Server fällt aus, die anderen übernehmen
• Kosteneffizient bei grosser Last

Nachteile:

• Komplexere Architektur
• Deine App muss dafür gebaut sein (stateless)
• Load Balancing nötig

Die Realität für Startups

Starte mit vertikaler Skalierung. Plane für horizontale Skalierung. Der Trick ist, deine Architektur von Anfang an so zu gestalten, dass der Wechsel später möglich ist.

Die Wachstumsphasen eines Startups

Phase 1: 0-1.000 Nutzer -- Der Einfache Server

In dieser Phase reicht ein einzelner Server völlig aus. Fokussiere dich auf dein Produkt, nicht auf die Infrastruktur.

Setup:

• 1 Server (Hetzner CX21: 2 vCPU, 4 GB RAM) -- 6 EUR/Monat
• Datenbank auf demselben Server
• Einfaches Deployment per Docker Compose

Kosten: 6-15 EUR/Monat

Nutzer -> Server (App + DB)

Was du jetzt schon richtig machen solltest:

• Docker verwenden (für spätere Migration)
• Stateless App-Design (Sessions nicht im Speicher)
• Umgebungsvariablen für Konfiguration
• Automatische Backups

Phase 2: 1.000-10.000 Nutzer -- Datenbank trennen

Wenn dein Server langsamer wird, trenne als Erstes die Datenbank auf einen eigenen Server. Das ist der grösste Performance-Gewinn mit dem geringsten Aufwand.

Setup:

• 1 App-Server (Hetzner CX31: 4 vCPU, 8 GB RAM) -- 12 EUR/Monat
• 1 Datenbank-Server (Hetzner CX31) -- 12 EUR/Monat
• Optional: CDN für statische Assets

Kosten: 25-50 EUR/Monat

Nutzer -> App-Server -> Datenbank-Server
                    -> CDN (statische Dateien)

Phase 3: 10.000-100.000 Nutzer -- Load Balancing

Jetzt brauchst du mehrere App-Server hinter einem Load Balancer. Das erfordert eine stateless Architektur.

Setup:

• 1 Load Balancer -- 5 EUR/Monat
• 2-4 App-Server -- 24-48 EUR/Monat
• 1 Datenbank-Server (grösser) -- 25 EUR/Monat
• Redis für Sessions und Caching -- 6 EUR/Monat
• CDN für statische Assets

Kosten: 60-150 EUR/Monat

Nutzer -> Load Balancer -> App-Server 1 -> Datenbank
                        -> App-Server 2 -> Redis Cache
                        -> App-Server 3

Phase 4: 100.000+ Nutzer -- Managed Services

Ab hier wird es komplex. Du brauchst Managed Services, Auto-Scaling, und wahrscheinlich einen dedizierten DevOps-Engineer.

Setup:

• Managed Kubernetes oder ECS
• Managed Database (RDS, Cloud SQL)
• Auto-Scaling Groups
• CDN mit Edge Computing
• Mehrere Availability Zones

Kosten: 500+ EUR/Monat

Stateless Architecture -- Die Grundlage für Skalierung

Die wichtigste Voraussetzung für horizontale Skalierung: Deine App darf keinen Zustand (State) im Speicher halten.

Was "stateless" bedeutet

Jeder Request muss unabhängig von vorherigen Requests bearbeitet werden können. Egal, welcher Server den Request bekommt.

Was du NICHT tun solltest

// FALSCH: Sessions im Speicher
const sessions = {};
app.use((req, res, next) => {
    const sessionId = req.cookies.sessionId;
    req.session = sessions[sessionId]; // Nur auf DIESEM Server verfuegbar
    next();
});

Was du STATTDESSEN tun solltest

// RICHTIG: Sessions in Redis
const RedisStore = require('connect-redis').default;
const redis = require('redis');

const redisClient = redis.createClient({ url: process.env.REDIS_URL });

app.use(session({
    store: new RedisStore({ client: redisClient }),
    secret: process.env.SESSION_SECRET,
    resave: false,
    saveUninitialized: false,
}));

Checkliste für Stateless Design

• Sessions werden extern gespeichert (Redis, Datenbank)
• Uploads gehen in Object Storage (S3, Hetzner Storage), nicht auf die lokale Festplatte
• Caches sind extern (Redis, Memcached)
• Konfiguration kommt aus Umgebungsvariablen
• Keine lokalen Dateien, die zwischen Requests benötigt werden

Datenbank-Skalierung

Die Datenbank ist oft der Flaschenhals. Hier sind die wichtigsten Strategien:

Read Replicas

Erstelle Kopien deiner Datenbank, die nur Lesezugriffe verarbeiten. Die meisten Anwendungen haben deutlich mehr Lese- als Schreibzugriffe.

Schreibzugriffe -> Primary Database
Lesezugriffe    -> Read Replica 1
                -> Read Replica 2

Connection Pooling

Datenbankverbindungen sind teuer. Nutze einen Connection Pool, um Verbindungen wiederzuverwenden:

const { Pool } = require('pg');

const pool = new Pool({
    connectionString: process.env.DATABASE_URL,
    max: 20,          // Maximal 20 Verbindungen
    idleTimeoutMillis: 30000,
    connectionTimeoutMillis: 2000,
});

Indexierung

Bevor du Hardware draufwirfst, prüfe deine Datenbankindizes. Ein fehlender Index kann einen Query von 5 Sekunden auf 5 Millisekunden bringen.

-- Langsame Queries finden (PostgreSQL)
SELECT query, mean_exec_time, calls
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 10;

-- Index erstellen
CREATE INDEX idx_orders_user_id ON orders(user_id);
CREATE INDEX idx_orders_created_at ON orders(created_at);

Caching

Nicht jeder Request muss die Datenbank treffen. Nutze Redis für häufig abgefragte Daten:

async function getProduct(productId) {
    // Erst im Cache schauen
    const cached = await redis.get(`product:${productId}`);
    if (cached) return JSON.parse(cached);

    // Wenn nicht im Cache, aus DB laden
    const product = await db.query('SELECT * FROM products WHERE id = $1', [productId]);

    // Im Cache speichern (1 Stunde)
    await redis.setex(`product:${productId}`, 3600, JSON.stringify(product));

    return product;
}

CDN -- Content Delivery Network

Ein CDN speichert statische Dateien (Bilder, CSS, JavaScript) auf Servern weltweit und liefert sie von dem Server, der dem Nutzer am nächsten ist.

Wann du ein CDN brauchst

• Deine App hat viele Bilder oder Videos
• Du hast Nutzer in verschiedenen Ländern
• Du willst deinen Server entlasten

Empfohlene CDNs

Cloudflare einrichten

1. Domain bei Cloudflare registrieren oder DNS umziehen
2. SSL auf "Full (Strict)" setzen
3. Caching Rules konfigurieren
4. Page Rules für statische Assets erstellen

Zeitaufwand: 30 Minuten. Kosten: 0 EUR.

Load Balancing

Wenn du mehrere App-Server hast, brauchst du einen Load Balancer, der eingehende Requests verteilt.

Optionen

Hetzner Load Balancer: 5 EUR/Monat -- einfach, zuverlässig, integriert mit Hetzner Cloud.

Caddy als Load Balancer:

deine-app.at {
    reverse_proxy app1:3000 app2:3000 app3:3000 {
        lb_policy round_robin
        health_uri /health
        health_interval 10s
    }
}

Nginx als Load Balancer:

upstream app_servers {
    least_conn;
    server app1:3000;
    server app2:3000;
    server app3:3000;
}

server {
    listen 80;
    server_name deine-app.at;

    location / {
        proxy_pass http://app_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Auto-Scaling -- Automatisch skalieren

Wenn dein Traffic schwankt, willst du nicht manuell Server hoch- und runterfahren. Auto-Scaling erledigt das automatisch.

Hetzner Cloud mit Terraform

resource "hcloud_server" "app" {
  count       = var.app_server_count
  name        = "app-${count.index + 1}"
  server_type = "cx21"
  image       = "docker-ce"
  location    = "nbg1"
}

resource "hcloud_load_balancer_target" "app" {
  count            = var.app_server_count
  type             = "server"
  load_balancer_id = hcloud_load_balancer.lb.id
  server_id        = hcloud_server.app[count.index].id
}

Du kannst app_server_count erhöhen und terraform apply ausführen -- schon hast du mehr Server.

AWS Auto-Scaling

Bei AWS geht das komplett automatisch basierend auf Metriken wie CPU-Auslastung:

# AWS CDK / CloudFormation Konzept
AutoScalingGroup:
  MinSize: 2
  MaxSize: 10
  TargetTrackingScaling:
    TargetValue: 70  # CPU-Auslastung in Prozent

Performance-Optimierung vor Skalierung

Bevor du mehr Server hinzufügst, optimiere erst, was du hast. Oft bringt Optimierung mehr als Skalierung.

Quick Wins

1. Gzip/Brotli Komprimierung: Reduziert die übertragene Datenmenge um 60-80%
2. Datenbankindizes: Der grösste Performance-Hebel
3. Caching: Redis für häufig abgefragte Daten
4. CDN für statische Assets: Entlastet deinen Server
5. Connection Pooling: Datenbank- und HTTP-Verbindungen wiederverwenden
6. Lazy Loading: Bilder und Inhalte erst laden, wenn sie sichtbar werden

Performance messen

Bevor du optimierst, musst du wissen, wo das Problem liegt:

# API Response Time messen
curl -o /dev/null -s -w "Time: %{time_total}s\n" https://deine-app.at/api/products

# Load Testing mit k6
k6 run --vus 100 --duration 60s loadtest.js

Der Skalierungsplan für dein Startup

Erstelle einen einfachen Plan, der beschreibt, was du bei welcher Nutzerzahl tust:

Wichtig: Das sind ungefähre Richtwerte. Deine tatsächlichen Kosten hängen von deinem spezifischen Workload ab.

Dont-Premature-Optimize -- Aber plane voraus

Die grösste Gefahr ist, zu früh zu viel Infrastruktur aufzubauen. Das kostet Geld und Zeit, die du für dein Produkt brauchst. Gleichzeitig willst du nicht überrascht werden.

Die goldene Regel: Baue für heute, plane für morgen, träume für übermorgen.

Das bedeutet konkret:

• Heute: Ein Server mit Docker
• Morgen: Stateless Design, das horizontal skalieren kann
• Übermorgen: Der tatsächliche Umbau erfolgt erst, wenn es nötig ist

Fazit

Skalierbare Infrastruktur ist kein Luxus -- sie ist eine Notwendigkeit, wenn dein Startup Erfolg hat. Aber Skalierung muss nicht teuer oder komplex sein. Starte einfach, plane voraus, und baue Schritt für Schritt aus.

Die wichtigsten Grundlagen: Stateless Design, Container, externe Datenhaltung. Wenn du diese Prinzipien von Anfang an berücksichtigst, ist der Weg von 100 zu 100.000 Nutzern machbar -- ohne alles neu bauen zu müssen.

Und vergiss nicht: Viele Skalierungsprobleme lassen sich durch Optimierung lösen, bevor du neue Hardware brauchst. Ein gut platzierter Datenbankindex kann Wunder wirken.

Startup Burgenland unterstützt dich

Du stehst vor der Herausforderung, deine Infrastruktur zu skalieren? Bei Startup Burgenland helfen wir dir, den richtigen Skalierungsplan für dein Startup zu erstellen. Unsere Mentoren kennen die typischen Wachstumsphasen und können dir helfen, die richtigen Entscheidungen zur richtigen Zeit zu treffen.

Jetzt Beratung anfragen

Weiterführende Artikel

• Cloud-Hosting für Startups -- AWS Azure oder Hetzner
• Serverless Architecture für Startups
• Tech-Stack Entscheidungen für Startups
• Künstliche Intelligenz und AGI -- Was kommt als Nächstes für Startups?
• Monitoring und Alerting einrichten

Dieser Beitrag ist Teil der Serie "Cloud und Infrastruktur" im Startup Burgenland Blog. In dieser Serie behandeln wir alle technischen Themen rund um Hosting, Deployment und Skalierung -- speziell für österreichische Startups und Gründer.

Über den Autor: Felix Lenhard ist Program Director und Startup Coach bei Startup Burgenland. Zuvor Managing Director beim 360 Innovation Lab, Innovation Manager bei RHI Magnesita und Serial Entrepreneur mit internationalen Exits. Über 15 Jahre Erfahrung in Innovation und Unternehmensaufbau.