Modernes System-Design einer hochskalierbaren Anwendung

Ich möchte hier anhand eines Beispiels einer einfachen URL Shortener erklären wie man eine moderne Systemarchitektur plant.

Inhaltsverzeichnis

  1. Überblick: Was soll das System tun?
  2. Anforderungen
  3. Problemstellung: Warum brauchen wir diese Architektur?
  4. System-Architektur
  5. Redis-Caching-Strategie: Warum und wie?
  6. Load Balancing: Was macht ein Load-Balancer genau?
  7. Skalierbarkeit: Warum horizontale Skalierung?
  8. Erweiterte Optimierungen
  9. Zusammenfassung

Überblick: Was soll das System tun?

Am Anfang überlegen wir uns wie wir generell die Short-URLs Designen. Dazu beginnen wir was eigentlich gemacht werden soll:

  1. User gibt eine lange URL ein
  2. Die URL wird von einem API-Endpunkt entgegen genommen und gibt eine Short-URL zurück und speichert die Short-URL in einer Datenbank
  3. Der User ruft die Short-URL auf, es wird in einer Datenbank nachgeschaut ob die Short-URL vorhanden ist, holt die Value und schickt den Nutzer mit einem HTTP-301 weiter.

Anforderungen

Problemstellung: Warum brauchen wir diese Architektur?

Bevor wir in die Details gehen, müssen wir verstehen, welche Probleme wir lösen müssen. Ein naives System mit nur einem Server und einer Datenbank würde bei steigender Last schnell an seine Grenzen stoßen.

Problem 1: Datenbank-Performance als Flaschenhals

Das Problem: Stellen Sie sich vor, Sie haben 10.000 Anfragen pro Sekunde für Redirects. Jede Anfrage muss:

  1. Eine Datenbankverbindung aufbauen (5-10ms Overhead)
  2. Eine SQL-Query ausführen (10-50ms je nach Last)
  3. Das Ergebnis zurückgeben

Bei 10.000 Anfragen/Sekunde bedeutet das:

Die Lösung: Redis als In-Memory-Cache reduziert Datenbankzugriffe um 95-99%.

Problem 2: Single Point of Failure

Das Problem: Ein einzelner Server kann:

Wenn dieser eine Server ausfällt, ist die gesamte Anwendung offline.

Die Lösung: Mehrere Server (horizontale Skalierung) + Load-Balancer sorgen für:

Problem 3: Skalierbarkeits-Limits

Das Problem: Ein einzelner Server hat physikalische Limits:

Wenn Sie wachsen, müssen Sie entweder:

Die Lösung: Horizontale Skalierung mit Load-Balancer ermöglicht praktisch unbegrenztes Wachstum.

Problem 4: Latenz und Benutzererfahrung

Das Problem: Benutzer erwarten Antwortzeiten unter 100ms. Bei einer Datenbank-Query:

Die Lösung: Redis liefert Antworten in <1ms, was die Benutzererfahrung drastisch verbessert.

System-Architektur

Wichtiger Hinweis: Alle Code-Beispiele in diesem Tutorial sind vereinfachte Meta-Code-Beispiele zur Veranschaulichung der Konzepte und Logik. Sie dienen dem Verständnis der System-Architektur und sind nicht als vollständige, produktionsreife Implementierungen gedacht. In einer produktiven Umgebung wären zusätzlich zu berücksichtigen: umfassende Fehlerbehandlung, Input-Validierung, Security-Best-Practices, Logging, Monitoring, Connection-Pooling, Migrationen, Tests, Dokumentation und viele weitere Aspekte.

Komponenten-Übersicht

Unser System besteht aus folgenden Komponenten:

┌─────────────┐
│   Client    │
└──────┬──────┘
       ▼
┌─────────────────┐
│  Load Balancer  │
└──────┬──────────┘
       ├──────────────┬──────────────┐
       ▼              ▼              ▼
┌──────────┐   ┌──────────┐   ┌──────────┐
│  API-1   │   │  API-2   │   │  API-3   │  (Horizontale Skalierung)
└────┬─────┘   └────┬─────┘   └────┬─────┘
     └──────┬───────┴──────┬───────┘
            ▼              ▼
      ┌─────────┐    ┌─────────┐
      │  Cache  │    │   DB    │  
      └─────────┘    └─────────┘

1. Datenbank-Design

Hinweis: Die folgenden Code-Beispiele sind vereinfachte Meta-Code-Beispiele zur Veranschaulichung der Konzepte. In einer produktiven Umgebung wären zusätzliche Aspekte wie Fehlerbehandlung, Validierung, Migrationen etc. zu berücksichtigen.

Zuerst müssen wir die Datenbank-Struktur definieren. Wir benötigen eine Tabelle für die URL-Mappings:

SQL Schema (Meta-Code Beispiel):

-- Vereinfachtes Schema zur Veranschaulichung
-- In Produktion: Weitere Indizes, Constraints, Partitionierung etc.

CREATE TABLE url_mappings (
    id BIGSERIAL PRIMARY KEY,                    -- Eindeutige ID
    short_code VARCHAR(7) UNIQUE NOT NULL,       -- 7-stelliger Code
    original_url TEXT NOT NULL,                  -- Original-URL
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    access_count BIGINT DEFAULT 0,                -- Optional: Analytics
    INDEX idx_short_code (short_code)            -- Index für schnelle Lookups
);

Wichtige Überlegungen:

2. Short-Code-Generierung

Der Short-Code wird aus einer eindeutigen ID generiert. Hier ist ein vereinfachtes Meta-Code-Beispiel:

Meta-Code Beispiel (Python-ähnlich):

# Vereinfachtes Beispiel zur Veranschaulichung
# In Produktion: Kollisionsprüfung, Retry-Logik etc.

import base64
import hashlib

def generate_short_code(url_id: int) -> str:
    """
    Generiert einen 7-stelligen Base64-kodierten Short-Code
    aus einer numerischen ID.
    
    Logik:
    1. Konvertiere ID zu Bytes
    2. Base64-kodiere
    3. Kürze auf 7 Zeichen
    """
    id_bytes = url_id.to_bytes(8, byteorder='big')
    encoded = base64.urlsafe_b64encode(id_bytes).decode('utf-8')
    short_code = encoded[:7].rstrip('=')
    return short_code

# Alternative: Hash-basiert (für bessere Verteilung)
def generate_short_code_from_url(url: str, salt: str = "") -> str:
    """
    Generiert einen Short-Code aus der URL selbst.
    Vorteil: Deterministisch (gleiche URL = gleicher Code)
    """
    hash_input = (url + salt).encode('utf-8')
    hash_bytes = hashlib.sha256(hash_input).digest()[:5]
    encoded = base64.urlsafe_b64encode(hash_bytes).decode('utf-8')
    return encoded[:7].rstrip('=')

3. API-Endpunkte

Hinweis: Die folgenden Code-Beispiele sind vereinfachte Meta-Code-Beispiele zur Veranschaulichung der Logik. In Produktion wären zusätzlich zu implementieren: Input-Validierung, Rate-Limiting, umfassende Fehlerbehandlung, Logging, Monitoring, Connection-Pooling etc.

POST /api/shorten

API-Spezifikation:

Request:

{
  "url": "https://www.example.com/very/long/url/path"
}

Response:

{
  "short_code": "aB3dEfG",
  "short_url": "https://short.ly/aB3dEfG",
  "original_url": "https://www.example.com/very/long/url/path"
}

Meta-Code Implementierung (vereinfacht):

# Meta-Code: Vereinfachtes Beispiel zur Veranschaulichung der Logik
# Framework-agnostisch dargestellt

@app.route('/api/shorten', methods=['POST'])
def shorten_url():
    # 1. Request-Daten extrahieren
    original_url = request.get_json()['url']
    
    # 2. Cache-Check: Existiert bereits ein Short-Code für diese URL?
    cache_key = f"url:{original_url}"
    cached_code = redis.get(cache_key)
    
    if cached_code:
        # Cache-Hit: Gebe existierenden Code zurück
        return {
            'short_code': cached_code,
            'short_url': f'https://short.ly/{cached_code}',
            'original_url': original_url
        }
    
    # 3. Cache-Miss: Erstelle neuen Eintrag
    # 3a. Generiere Short-Code
    url_id = db.get_next_id()  # Oder Auto-Increment
    short_code = generate_short_code(url_id)
    
    # 3b. Speichere in Datenbank
    db.insert('url_mappings', {
        'short_code': short_code,
        'original_url': original_url
    })
    
    # 3c. Cache speichern (beide Richtungen)
    redis.setex(f"url:{original_url}", 3600, short_code)
    redis.setex(f"code:{short_code}", 86400, original_url)
    
    # 4. Response zurückgeben
    return {
        'short_code': short_code,
        'short_url': f'https://short.ly/{short_code}',
        'original_url': original_url
    }

Logik-Flow:

  1. Cache-Check: Prüfe ob URL bereits existiert → verhindert Duplikate
  2. Code-Generierung: Erstelle neuen eindeutigen Short-Code
  3. Datenbank-Speicherung: Persistiere Mapping
  4. Cache-Update: Speichere in beide Richtungen für schnelle Lookups

GET /{short_code}

API-Spezifikation:

Request:

GET /abc123

Response:

HTTP 301 Redirect
Location: https://www.example.com/very/long/url/path

Meta-Code Implementierung (vereinfacht):

# Meta-Code: Vereinfachtes Beispiel zur Veranschaulichung der Logik

@app.route('/<short_code>', methods=['GET'])
def redirect_to_url(short_code):
    # 1. Cache-Check: Ist URL im Cache?
    cache_key = f"code:{short_code}"
    cached_url = redis.get(cache_key)
    
    if cached_url:
        # Cache-Hit: Sofortiger Redirect (sehr schnell: <1ms)
        return redirect(cached_url, code=301)
    
    # 2. Cache-Miss: Hole aus Datenbank
    original_url = db.query(
        "SELECT original_url FROM url_mappings WHERE short_code = ?",
        short_code
    )
    
    if not original_url:
        return error(404, 'Short URL not found')
    
    # 3. Cache für zukünftige Anfragen speichern
    redis.setex(cache_key, 86400, original_url)  # 24 Stunden
    
    # 4. Optional: Access-Count asynchron aktualisieren
    # (Nicht blockierend, läuft im Hintergrund)
    async_update_access_count(short_code)
    
    # 5. Redirect zurückgeben
    return redirect(original_url, code=301)

Logik-Flow:

  1. Cache-Check: Prüfe ob Short-Code im Cache → 95-99% der Fälle
  2. Datenbank-Fallback: Falls nicht im Cache → Hole aus DB
  3. Cache-Update: Speichere für zukünftige Anfragen
  4. Redirect: HTTP 301 Permanent Redirect zur Original-URL

4. Redis-Caching-Strategie: Warum und wie?

Warum Redis? Das Performance-Problem verstehen

Ohne Redis (nur Datenbank):

Anfrage → API-Server → Datenbank-Query (50ms) → Antwort

Bei 10.000 Anfragen/Sekunde:

Mit Redis (Cache-Layer):

Anfrage → API-Server → Redis-Cache (0.1ms) → Antwort
         ↓ (Cache-Miss, 5% der Fälle)
         → Datenbank-Query (50ms) → Cache speichern → Antwort

Bei 10.000 Anfragen/Sekunde:

Was macht Redis genau?

Redis ist ein In-Memory-Datenbank (alle Daten im RAM), was sie extrem schnell macht:

OperationDatenbank (PostgreSQL)Redis
Einfacher Read5-50ms0.1-1ms
Einfacher Write10-100ms0.1-1ms
Durchsatz1.000-10.000 Ops/s100.000-1.000.000 Ops/s

Warum ist Redis so schnell?

  1. Keine Festplatten-I/O: Alles im RAM (1000x schneller als SSD)
  2. Einfache Datenstrukturen: Key-Value-Store ohne komplexe Joins
  3. Single-threaded: Keine Locks, keine Race-Conditions
  4. Optimiert für Geschwindigkeit: C-Implementierung, minimaler Overhead

Cache-Strategien im Detail

Redis wird für zwei kritische Zwecke verwendet:

1. URL → Short-Code Cache (Verhindert Duplikate)

Problem ohne Cache:

# User sendet gleiche URL zweimal
POST /api/shorten {"url": "https://example.com"}
→ Datenbank-Query: "SELECT * WHERE url = ..." (50ms)
→ Nicht gefunden → Neuer Eintrag erstellt

POST /api/shorten {"url": "https://example.com"}  # Gleiche URL!
→ Datenbank-Query: "SELECT * WHERE url = ..." (50ms)
→ Nicht gefunden → Noch ein Eintrag erstellt (DUPLIKAT!)

Lösung mit Cache:

# Erste Anfrage
POST /api/shorten {"url": "https://example.com"}
→ Redis-Check: "GET url:https://example.com" (0.1ms)
→ Nicht gefunden → Datenbank → Cache speichern
→ Redis: "SETEX url:https://example.com 3600 abc123"

# Zweite Anfrage (gleiche URL)
POST /api/shorten {"url": "https://example.com"}
→ Redis-Check: "GET url:https://example.com" (0.1ms)
→ Gefunden! → Sofort zurückgeben (keine Datenbank-Query)

2. Short-Code → URL Cache (Beschleunigt Redirects)

Das Problem: Redirects sind der häufigste Operationstyp (99% aller Anfragen). Jeder Redirect ohne Cache bedeutet:

Bei 1 Million Redirects/Tag = 11.5 Redirects/Sekunde → Datenbank wird überlastet.

Die Lösung:

# Redirect-Anfrage
GET /abc123
→ Redis: "GET code:abc123" (0.1ms)
→ Gefunden! → Sofortiger Redirect (keine Datenbank-Query)

Cache-Hit-Rate Optimierung:

Eine gute Cache-Hit-Rate liegt bei 95-99%. Das bedeutet:

Cache-Strategie im Code (Meta-Code Beispiel):

# Meta-Code: Vereinfachtes Beispiel zur Veranschaulichung
# Cache-Aside Pattern: Cache wird "neben" der Datenbank verwendet

# Beim Erstellen einer Short-URL
# Cache in beide Richtungen für schnelle Lookups
redis.setex(f"url:{original_url}", 3600, short_code)      # URL → Code (1 Stunde)
redis.setex(f"code:{short_code}", 86400, original_url)    # Code → URL (24 Stunden)

# Beim Abrufen (Cache-Aside Pattern)
def get_url_from_cache_or_db(short_code):
    # 1. Prüfe Cache zuerst (schnell: <1ms)
    cached_url = redis.get(f"code:{short_code}")
    if cached_url:
        return cached_url  # Cache-Hit: Sofort zurückgeben
    
    # 2. Cache-Miss: Hole aus Datenbank (langsam: 50ms)
    url = db.query("SELECT original_url WHERE short_code = ?", short_code)
    
    # 3. Speichere im Cache für zukünftige Anfragen
    if url:
        redis.setex(f"code:{short_code}", 86400, url)
    
    return url

Redis-Konfiguration und Memory-Management

Warum Memory-Limits wichtig sind:

Redis speichert alles im RAM. Ohne Limits würde Redis:

Redis-Konfiguration (redis.conf):

# Maximal 2GB RAM für Redis
maxmemory 2gb

# Eviction-Policy: Welche Keys werden gelöscht wenn Memory voll ist?
# allkeys-lru: Löscht am wenigsten genutzte Keys (LRU = Least Recently Used)
maxmemory-policy allkeys-lru

# Alternative Policies:
# - noeviction: Keine Keys löschen (Fehler wenn voll)
# - allkeys-lfu: Löscht am wenigsten häufig genutzte Keys
# - volatile-lru: Löscht nur Keys mit TTL

TTL (Time-To-Live) Strategie (Meta-Code Beispiel):

# Meta-Code: Beispiel für unterschiedliche TTL-Strategien
# TTL bestimmt, wie lange Daten im Cache bleiben

# Kurze TTL für selten genutzte/temporäre Daten
redis.setex("temp:session:123", 300, data)              # 5 Minuten

# Mittlere TTL für normale Daten
redis.setex("url:https://example.com", 3600, code)       # 1 Stunde

# Lange TTL für häufig genutzte, stabile Daten
redis.setex("code:abc123", 86400, url)                   # 24 Stunden

Warum unterschiedliche TTLs?

Redis-Cluster für hohe Verfügbarkeit

Problem: Single Redis-Instanz

Wenn Redis ausfällt:

Lösung: Redis-Cluster oder Redis-Sentinel

┌─────────┐    ┌─────────┐    ┌─────────┐
│ Redis-1 │    │ Redis-2 │    │ Redis-3 │
│ (Master)│◄───┤(Replica)│◄───┤(Replica)│
└─────────┘    └─────────┘    └─────────┘
     │              │              │
     └──────────────┴──────────────┘
                    │
              ┌─────────┐
              │ Sentinel│  (Überwacht Master, failover bei Ausfall)
              └─────────┘

Vorteile:

5. Load Balancing: Was macht ein Load-Balancer genau?

Das Problem: Warum brauchen wir einen Load-Balancer?

Ohne Load-Balancer (ein Server):

Client → API-Server (10.000 Anfragen/Sekunde)

Probleme:

  1. Single Point of Failure: Wenn Server ausfällt, ist alles offline
  2. Performance-Limit: Ein Server kann nur begrenzte Anfragen verarbeiten
  3. Wartungsprobleme: Server muss offline für Updates
  4. Ressourcen-Limit: CPU/Memory-Limits werden erreicht

Mit Load-Balancer (mehrere Server):

Client → Load-Balancer → API-Server-1 (3.333 Anfragen/Sekunde)
                       → API-Server-2 (3.333 Anfragen/Sekunde)
                       → API-Server-3 (3.333 Anfragen/Sekunde)

Vorteile:

  1. Hochverfügbarkeit: Wenn ein Server ausfällt, übernehmen die anderen
  2. Skalierbarkeit: Mehr Server = mehr Kapazität
  3. Wartbarkeit: Server können einzeln aktualisiert werden
  4. Lastverteilung: Kein Server wird überlastet

Was macht ein Load-Balancer genau?

Ein Load-Balancer ist ein Reverse-Proxy, der zwischen Clients und Servern sitzt und Anfragen intelligent verteilt.

Funktionsweise im Detail:

1. Client sendet Anfrage an Load-Balancer
   GET https://short.ly/abc123

2. Load-Balancer analysiert Anfrage
   - Welche Server sind verfügbar?
   - Welcher Server hat am wenigsten Last?
   - Welcher Algorithmus soll verwendet werden?

3. Load-Balancer wählt Server aus
   → API-Server-2 (geringste Last)

4. Load-Balancer leitet Anfrage weiter
   GET http://api-2:5000/abc123

5. Server verarbeitet Anfrage
   → Redis-Check → Redirect

6. Antwort geht zurück durch Load-Balancer
   HTTP 301 → Client

Load-Balancing-Algorithmen

1. Round-Robin (Standard)

Wie es funktioniert:

Beispiel:

Anfrage 1 → Server 1
Anfrage 2 → Server 2
Anfrage 3 → Server 3
Anfrage 4 → Server 1
Anfrage 5 → Server 2

Vorteile:

Nachteile:

2. Least Connections

Wie es funktioniert:

Beispiel:

Server 1: 100 aktive Verbindungen
Server 2: 50 aktive Verbindungen  ← Wird gewählt
Server 3: 75 aktive Verbindungen

Vorteile:

3. Weighted Round-Robin

Wie es funktioniert:

Beispiel:

Server 1 (Gewicht 3): 3 Anfragen
Server 2 (Gewicht 1): 1 Anfrage
Server 1: 3 Anfragen
Server 2: 1 Anfrage

Vorteile:

4. IP Hash (Sticky Sessions)

Wie es funktioniert:

Beispiel:

Client 192.168.1.1 → Hash → Server 2 (immer)
Client 192.168.1.2 → Hash → Server 1 (immer)

Vorteile:

Nachteile:

Health Checks: Warum sind sie kritisch?

Das Problem ohne Health Checks:

Server 2 ist abgestürzt, aber Load-Balancer weiß es nicht
→ Anfragen werden weiterhin an Server 2 gesendet
→ Client erhält Fehler (Timeout, 500 Error)
→ 33% der Anfragen schlagen fehl

Die Lösung: Health Checks

Ein Load-Balancer überprüft regelmäßig, ob Server erreichbar sind:

# Traefik Health Check Konfiguration
healthcheck:
  path: /health
  interval: 10s      # Alle 10 Sekunden prüfen
  timeout: 3s       # Timeout nach 3 Sekunden
  retries: 3        # 3 Fehlversuche = Server als "down" markieren

Health Check Endpoint im API-Server (Meta-Code Beispiel):

# Meta-Code: Vereinfachtes Beispiel zur Veranschaulichung
# In Produktion: Timeouts, detaillierte Checks, Metriken etc.

@app.route('/health', methods=['GET'])
def health_check():
    # Prüfe kritische Komponenten
    try:
        # 1. Redis erreichbar?
        redis.ping()
        
        # 2. Datenbank erreichbar?
        db.ping()  # Oder einfache Query
        
        # 3. Optional: Weitere Checks
        # - Disk Space
        # - Memory Usage
        # - External Services
        
        return {'status': 'healthy'}, 200
    except Exception as e:
        # Fehler: Server als "unhealthy" markieren
        return {'status': 'unhealthy', 'error': str(e)}, 503

Health Check Workflow:

1. Load-Balancer sendet GET /health an Server
2. Server prüft: Redis OK? Datenbank OK?
3. Server antwortet: 200 OK oder 503 Unhealthy
4. Load-Balancer markiert Server als "up" oder "down"
5. Nur "up" Server erhalten Anfragen

Vorteile:

Session-Persistenz (Sticky Sessions)

Das Problem:

Bei Stateful-Anwendungen (z.B. Shopping-Cart):

Request 1: Client → Load-Balancer → Server 1 (Cart wird erstellt)
Request 2: Client → Load-Balancer → Server 2 (Cart ist leer! Problem!)

Die Lösung: Sticky Sessions

# Traefik Cookie-basierte Session-Persistenz
labels:
  - "traefik.http.services.api.loadbalancer.sticky.cookie=true"
  - "traefik.http.services.api.loadbalancer.sticky.cookie.name=server_id"

Wie es funktioniert:

  1. Erste Anfrage → Load-Balancer wählt Server 1
  2. Load-Balancer setzt Cookie: server_id=server1
  3. Weitere Anfragen → Cookie wird gelesen → Immer Server 1

Für unser URL-Shortener:

SSL/TLS Termination

Was ist SSL/TLS Termination?

Der Load-Balancer übernimmt die SSL-Entschlüsselung:

Client → [HTTPS verschlüsselt] → Load-Balancer → [HTTP unverschlüsselt] → API-Server

Vorteile:

Traefik SSL-Konfiguration:

traefik:
  command:
    - "--certificatesresolvers.letsencrypt.acme.email=admin@short.ly"
    - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
    - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web"
  volumes:
    - ./letsencrypt:/letsencrypt

Rate Limiting und DDoS-Schutz

Das Problem: DDoS-Angriffe

Angreifer sendet 100.000 Anfragen/Sekunde
→ Ohne Rate Limiting: Alle Server überlastet
→ System bricht zusammen

Die Lösung: Rate Limiting im Load-Balancer

# Traefik Rate Limiting
labels:
  - "traefik.http.middlewares.ratelimit.ratelimit.average=100"
  - "traefik.http.middlewares.ratelimit.ratelimit.period=1s"
  - "traefik.http.routers.api.middlewares=ratelimit"

Wie es funktioniert:

Traefik-Konfiguration: Vollständiges Beispiel

docker-compose.yml für Traefik:

version: '3.8'

services:
  traefik:
    image: traefik:v2.10
    command:
      # API Dashboard (nur für Entwicklung)
      - "--api.insecure=true"
      
      # Docker Provider (automatische Service-Erkennung)
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      
      # Entry Points (Ports)
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      
      # SSL/TLS (Let's Encrypt)
      - "--certificatesresolvers.letsencrypt.acme.email=admin@short.ly"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web"
      
      # Logging
      - "--accesslog=true"
      - "--log.level=INFO"
    ports:
      - "80:80"      # HTTP
      - "443:443"    # HTTPS
      - "8080:8080"  # Traefik Dashboard
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./letsencrypt:/letsencrypt
    networks:
      - app-network

  api-1:
    build: ./api
    labels:
      # Traefik aktivieren
      - "traefik.enable=true"
      
      # Routing-Regeln
      - "traefik.http.routers.api.rule=Host(`short.ly`)"
      - "traefik.http.routers.api.entrypoints=web,websecure"
      - "traefik.http.routers.api.tls.certresolver=letsencrypt"
      
      # Service-Konfiguration
      - "traefik.http.services.api.loadbalancer.server.port=5000"
      
      # Load-Balancing-Algorithmus (Round-Robin ist Standard)
      # Für Least Connections:
      # - "traefik.http.services.api.loadbalancer.server.weight=1"
      
      # Health Checks
      - "traefik.http.services.api.loadbalancer.healthcheck.path=/health"
      - "traefik.http.services.api.loadbalancer.healthcheck.interval=10s"
      
      # Rate Limiting (optional)
      - "traefik.http.middlewares.ratelimit.ratelimit.average=100"
      - "traefik.http.routers.api.middlewares=ratelimit"
    networks:
      - app-network
    environment:
      - REDIS_HOST=redis
      - DB_HOST=postgres
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:5000/health"]
      interval: 10s
      timeout: 3s
      retries: 3

  api-2:
    build: ./api
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.api.rule=Host(`short.ly`)"
      - "traefik.http.routers.api.entrypoints=web,websecure"
      - "traefik.http.routers.api.tls.certresolver=letsencrypt"
      - "traefik.http.services.api.loadbalancer.server.port=5000"
      - "traefik.http.services.api.loadbalancer.healthcheck.path=/health"
      - "traefik.http.services.api.loadbalancer.healthcheck.interval=10s"
    networks:
      - app-network
    environment:
      - REDIS_HOST=redis
      - DB_HOST=postgres
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:5000/health"]
      interval: 10s
      timeout: 3s
      retries: 3

  api-3:
    build: ./api
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.api.rule=Host(`short.ly`)"
      - "traefik.http.routers.api.entrypoints=web,websecure"
      - "traefik.http.routers.api.tls.certresolver=letsencrypt"
      - "traefik.http.services.api.loadbalancer.server.port=5000"
      - "traefik.http.services.api.loadbalancer.healthcheck.path=/health"
      - "traefik.http.services.api.loadbalancer.healthcheck.interval=10s"
    networks:
      - app-network
    environment:
      - REDIS_HOST=redis
      - DB_HOST=postgres
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:5000/health"]
      interval: 10s
      timeout: 3s
      retries: 3

  redis:
    image: redis:7-alpine
    volumes:
      - redis-data:/data
    networks:
      - app-network
    command: redis-server --maxmemory 2gb --maxmemory-policy allkeys-lru

  postgres:
    image: postgres:15-alpine
    environment:
      - POSTGRES_DB=urlshortener
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=password
    volumes:
      - postgres-data:/var/lib/postgresql/data
    networks:
      - app-network

volumes:
  redis-data:
  postgres-data:

networks:
  app-network:
    driver: bridge

Monitoring und Metriken

Wichtige Load-Balancer-Metriken:

  1. Request-Rate: Anfragen pro Sekunde
  2. Response-Time: Durchschnittliche Antwortzeit
  3. Error-Rate: Prozent der fehlgeschlagenen Anfragen
  4. Server-Status: Welche Server sind “up” oder “down”?
  5. Lastverteilung: Wie viele Anfragen pro Server?

Traefik Dashboard:

Zugriff auf http://localhost:8080 zeigt:

6. Skalierbarkeit: Warum horizontale Skalierung?

Das Problem: Vertikale vs. Horizontale Skalierung

Vertikale Skalierung (Scale-Up):

Ein Server: 4 Cores, 8GB RAM
     ↓
Größerer Server: 8 Cores, 16GB RAM
     ↓
Noch größerer Server: 16 Cores, 32GB RAM

Probleme:

  1. Teuer: Größere Server kosten exponentiell mehr
  2. Limits: Irgendwann gibt es keine größeren Server mehr
  3. Downtime: Server muss offline für Hardware-Upgrade
  4. Single Point of Failure: Ein Server = ein Ausfallpunkt

Horizontale Skalierung (Scale-Out):

1 Server: 4 Cores, 8GB RAM
     ↓
3 Server: 12 Cores, 24GB RAM (gesamt)
     ↓
10 Server: 40 Cores, 80GB RAM (gesamt)

Vorteile:

  1. Kosteneffizient: Mehr kleine Server sind günstiger als ein großer
  2. Praktisch unbegrenzt: Kann beliebig viele Server hinzufügen
  3. Kein Downtime: Neue Server können live hinzugefügt werden
  4. Hochverfügbarkeit: Wenn ein Server ausfällt, übernehmen andere

Warum horizontale Skalierung für unseren URL-Shortener?

Szenario: Wachstum der Anwendung

Start: 100 Anfragen/Sekunde → 1 Server reicht
     ↓
Nach 6 Monaten: 1.000 Anfragen/Sekunde → 3 Server nötig
     ↓
Nach 1 Jahr: 10.000 Anfragen/Sekunde → 10 Server nötig
     ↓
Nach 2 Jahren: 100.000 Anfragen/Sekunde → 50 Server nötig

Mit vertikaler Skalierung:

Mit horizontaler Skalierung:

Anforderungen für horizontale Skalierung

1. Stateless API-Server

Was bedeutet “stateless”?

Ein stateless Server speichert keinen lokalen State (keine Session-Daten, kein lokaler Cache).

Stateless (gut für Skalierung):

# Jede Anfrage ist unabhängig
@app.route('/<short_code>')
def redirect(short_code):
    # Keine lokalen Variablen, keine Session-Daten
    url = get_url_from_redis_or_db(short_code)  # Externe Datenquelle
    return redirect(url)

Stateful (schlecht für Skalierung):

# Server speichert State lokal
session_data = {}  # Lokaler Speicher

@app.route('/<short_code>')
def redirect(short_code):
    # Problem: Wenn Request an anderen Server geht, ist State weg!
    if short_code in session_data:  # Nur auf diesem Server!
        return redirect(session_data[short_code])

Warum ist Stateless wichtig?

Request 1: Client → Load-Balancer → Server 1 (State gespeichert)
Request 2: Client → Load-Balancer → Server 2 (State fehlt! Problem!)

Mit stateless:

2. Shared Database

Warum eine gemeinsame Datenbank?

Server 1 erstellt: short.ly/abc123 → https://example.com
Server 2 erstellt: short.ly/xyz789 → https://test.com
Server 3 muss beide URLs kennen können!

Ohne Shared Database (jeder Server eigene DB):

Server 1 DB: abc123 → example.com
Server 2 DB: xyz789 → test.com
Server 3 DB: (leer)

Problem: Server 3 kennt abc123 und xyz789 nicht!

Mit Shared Database:

Alle Server → Gemeinsame Datenbank
Server 1: Erstellt abc123 → Speichert in DB
Server 2: Erstellt xyz789 → Speichert in DB
Server 3: Kann beide URLs abrufen → Liest aus DB

3. Shared Cache (Redis)

Warum ein gemeinsamer Cache?

Server 1: Cache für abc123 → example.com
Server 2: Cache für xyz789 → test.com
Server 3: Kein Cache

Problem: Server 3 muss immer zur Datenbank (langsam)

Mit Shared Cache:

Alle Server → Gemeinsamer Redis
Server 1: Cache für abc123 → Speichert in Redis
Server 2: Cache für xyz789 → Speichert in Redis
Server 3: Kann beide aus Redis lesen (schnell!)

4. Load Balancer

Warum ein Load-Balancer?

Ohne Load-Balancer müssten Clients wissen, welcher Server verfügbar ist:

Client muss wählen:
- Soll ich zu Server 1, 2 oder 3 gehen?
- Welcher Server ist verfügbar?
- Wie verteile ich Last gleichmäßig?

Mit Load-Balancer:

Client → Load-Balancer (wählt automatisch Server) → Server

Skalierung in der Praxis

Schritt 1: Start mit einem Server

services:
  api:
    build: ./api
    # Ein Server, kann ~1.000 Anfragen/Sekunde verarbeiten

Schritt 2: Skalierung bei steigender Last

# Docker Compose Skalierung
docker-compose up -d --scale api=3

# Jetzt: 3 Server, können ~3.000 Anfragen/Sekunde verarbeiten

Schritt 3: Automatische Skalierung (Auto-Scaling)

Bei Cloud-Providern (AWS, Google Cloud, Azure):

# Kubernetes Auto-Scaling Beispiel
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-autoscaler
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 3
  maxReplicas: 50
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Wie Auto-Scaling funktioniert:

CPU-Auslastung < 50% → Reduziere Server (z.B. 3 → 2)
CPU-Auslastung > 70% → Erhöhe Server (z.B. 3 → 5)
CPU-Auslastung > 90% → Erhöhe Server (z.B. 5 → 10)

Vorteile:

Skalierungs-Limits und Bottlenecks

Wichtige Überlegung: Wo sind die Limits?

1. API-Server (horizontale Skalierung möglich)

1 Server → 3 Server → 10 Server → 50 Server → 100 Server
✅ Praktisch unbegrenzt skalierbar

2. Load-Balancer (kann selbst skaliert werden)

1 Load-Balancer → 2 Load-Balancer (Active-Passive)
✅ Kann auch skaliert werden

3. Redis (kann zu Cluster erweitert werden)

1 Redis → Redis-Cluster (3-6 Nodes)
✅ Kann skaliert werden (Sharding)

4. Datenbank (kritischer Bottleneck!)

1 Datenbank → Read-Replicas (für Reads)
            → Master (für Writes)
⚠️ Writes sind schwerer zu skalieren

Datenbank-Skalierung:

Read-Replicas für bessere Read-Performance:

Master DB (Writes) → Replica 1 (Reads)
                  → Replica 2 (Reads)
                  → Replica 3 (Reads)

API-Server können Reads auf Replicas verteilen

Sharding für sehr große Datenmengen:

Shard 1: URLs a-m (20% der Daten)
Shard 2: URLs n-z (30% der Daten)
Shard 3: URLs 0-9 (50% der Daten)

Jeder Shard auf separatem Server

Skalierungsschritte: Praktisches Beispiel

Phase 1: MVP (1-100 Anfragen/Sekunde)

# 1 API-Server
docker-compose up -d

Phase 2: Wachstum (100-1.000 Anfragen/Sekunde)

# 3 API-Server
docker-compose up -d --scale api=3

Phase 3: Skalierung (1.000-10.000 Anfragen/Sekunde)

# 10 API-Server
docker-compose up -d --scale api=10

# Redis-Cluster für bessere Cache-Performance
# Datenbank Read-Replicas für bessere DB-Performance

Phase 4: Enterprise (10.000+ Anfragen/Sekunde)

# 50+ API-Server
# Redis-Cluster mit 6 Nodes
# Datenbank mit Sharding
# CDN für statische Inhalte
# Multi-Region Deployment

Monitoring der Skalierung

Wichtige Metriken zum Überwachen:

  1. Request-Rate: Anfragen pro Sekunde pro Server
  2. Response-Time: Durchschnittliche Antwortzeit
  3. CPU-Auslastung: Sollte < 70% sein für Puffer
  4. Memory-Auslastung: Sollte < 80% sein
  5. Error-Rate: Sollte < 1% sein
  6. Cache-Hit-Rate: Sollte > 95% sein

Wann sollte skaliert werden?

CPU > 70% für > 5 Minuten → Skaliere hoch
Response-Time > 200ms → Skaliere hoch
Error-Rate > 1% → Skaliere hoch
Cache-Hit-Rate < 90% → Prüfe Redis-Konfiguration

7. Erweiterte Optimierungen

Datenbank-Optimierung:

-- Partitionierung für große Tabellen
CREATE TABLE url_mappings_2025 PARTITION OF url_mappings
FOR VALUES FROM ('2025-01-01') TO ('2026-01-01');

-- Read Replicas für bessere Lesepfad-Performance

Caching-Optimierung:

Monitoring:

Zusammenfassung

Dieses System-Design bietet:

✅ Skalierbarkeit: Horizontale Skalierung durch stateless API-Server
✅ Performance: Redis-Caching für schnelle Antwortzeiten
✅ Zuverlässigkeit: Load Balancing verteilt Last gleichmäßig
✅ Einfachheit: Klare Trennung der Komponenten

Mit dieser Architektur können Sie Millionen von Short-URLs verwalten und tausende von Anfragen pro Sekunde verarbeiten.

Datenschutzerklärung

1. Datenschutz auf einen Blick

Allgemeine Hinweise

Die folgenden Hinweise geben einen einfachen Überblick darüber, was mit Ihren personenbezogenen Daten passiert, wenn Sie diese Website besuchen. Personenbezogene Daten sind alle Daten, mit denen Sie persönlich identifiziert werden können. Ausführliche Informationen zum Thema Datenschutz entnehmen Sie unserer unter diesem Text aufgeführten Datenschutzerklärung.

Datenerfassung auf dieser Website

Wer ist verantwortlich für die Datenerfassung auf dieser Website?

Die Datenverarbeitung auf dieser Website erfolgt durch den Websitebetreiber. Dessen Kontaktdaten können Sie dem Abschnitt „Hinweis zur Verantwortlichen Stelle" in dieser Datenschutzerklärung entnehmen.

Wie erfassen wir Ihre Daten?

Ihre Daten werden zum einen dadurch erhoben, dass Sie uns diese mitteilen. Hierbei kann es sich z. B. um Daten handeln, die Sie in ein Kontaktformular eingeben.

Andere Daten werden automatisch oder nach Ihrer Einwilligung beim Besuch der Website durch unsere IT-Systeme erfasst. Das sind vor allem technische Daten (z. B. Internetbrowser, Betriebssystem oder Uhrzeit des Seitenaufrufs). Die Erfassung dieser Daten erfolgt automatisch, sobald Sie diese Website betreten.

Wofür nutzen wir Ihre Daten?

Ein Teil der Daten wird erhoben, um eine fehlerfreie Bereitstellung der Website zu gewährleisten. Andere Daten können zur Analyse Ihres Nutzerverhaltens verwendet werden.

Welche Rechte haben Sie bezüglich Ihrer Daten?

Sie haben jederzeit das Recht, unentgeltlich Auskunft über Herkunft, Empfänger und Zweck Ihrer gespeicherten personenbezogenen Daten zu erhalten. Sie haben außerdem ein Recht, die Berichtigung oder Löschung dieser Daten zu verlangen. Wenn Sie eine Einwilligung zur Datenverarbeitung erteilt haben, können Sie diese Einwilligung jederzeit für die Zukunft widerrufen. Außerdem haben Sie das Recht, unter bestimmten Umständen die Einschränkung der Verarbeitung Ihrer personenbezogenen Daten zu verlangen. Des Weiteren steht Ihnen ein Beschwerderecht bei der zuständigen Aufsichtsbehörde zu.

Hierzu sowie zu weiteren Fragen zum Thema Datenschutz können Sie sich jederzeit an uns wenden.

2. Hosting

Wir hosten die Inhalte unserer Website bei folgendem Anbieter:

Die von uns in Anspruch genommenen Hosting-Leistungen dienen der Zurverfügungstellung der folgenden Leistungen: Infrastruktur- und Plattformdienstleistungen, Rechenkapazität, Speicherplatz und Datenbankdienste, Sicherheitsleistungen sowie technische Wartungsleistungen, die wir zum Zwecke des Betriebs dieser Website einsetzen.

Hierbei verarbeiten wir, bzw. unser Hostinganbieter Bestandsdaten, Kontaktdaten, Inhaltsdaten, Vertragsdaten, Nutzungsdaten, Meta- und Kommunikationsdaten von Kunden, Interessenten und Besuchern dieser Website auf Grundlage unserer berechtigten Interessen an einer effizienten und sicheren Zurverfügungstellung dieser Website gem. Art. 6 Abs. 1 lit. f DSGVO i.V.m. Art. 28 DSGVO.

3. Allgemeine Hinweise und Pflichtinformationen

Datenschutz

Die Betreiber dieser Seiten nehmen den Schutz Ihrer persönlichen Daten sehr ernst. Wir behandeln Ihre personenbezogenen Daten vertraulich und entsprechend den gesetzlichen Datenschutzbestimmungen sowie dieser Datenschutzerklärung.

Wenn Sie diese Website benutzen, werden verschiedene personenbezogene Daten erhoben. Personenbezogene Daten sind Daten, mit denen Sie persönlich identifiziert werden können. Die vorliegende Datenschutzerklärung erläutert, welche Daten wir erheben und wofür wir sie nutzen. Sie erläutert auch, wie und zu welchem Zweck das geschieht.

Wir weisen darauf hin, dass die Datenübertragung im Internet (z. B. bei der Kommunikation per E-Mail) Sicherheitslücken aufweisen kann. Ein lückenloser Schutz der Daten vor dem Zugriff durch Dritte ist nicht möglich.

Hinweis zur verantwortlichen Stelle

Die verantwortliche Stelle für die Datenverarbeitung auf dieser Website ist:

Van de Everest UG (haftungsbeschränkt)
Frankenstraße 152
90461 Nürnberg
Deutschland

Vertreten durch: Kai Pazdzewicz

Telefon: +49 (0) 911 14895050
E-Mail: info@pazdzewicz.de

Registergericht: Nürnberg
Registernummer: HRB 43972

Umsatzsteuer-ID: DE340033340

Verantwortliche Stelle ist die natürliche oder juristische Person, die allein oder gemeinsam mit anderen über die Zwecke und Mittel der Verarbeitung von personenbezogenen Daten (z. B. Namen, E-Mail-Adressen o. Ä.) entscheidet.

Speicherdauer

Soweit innerhalb dieser Datenschutzerklärung keine speziellere Speicherdauer genannt wurde, verbleiben Ihre personenbezogenen Daten bei uns, bis der Zweck für die Datenverarbeitung entfällt. Wenn Sie ein berechtigtes Löschersuchen geltend machen oder eine Einwilligung zur Datenverarbeitung widerrufen, werden Ihre Daten gelöscht, sofern wir keine anderen rechtlich zulässigen Gründe für die Speicherung Ihrer personenbezogenen Daten haben (z. B. steuer- oder handelsrechtliche Aufbewahrungsfristen); im letztgenannten Fall erfolgt die Löschung nach Fortfall dieser Gründe.

Allgemeine Hinweise zu den Rechtsgrundlagen der Datenverarbeitung auf dieser Website

Sofern Sie in die Datenverarbeitung eingewilligt haben, verarbeiten wir Ihre personenbezogenen Daten auf Grundlage von Art. 6 Abs. 1 lit. a DSGVO bzw. Art. 9 Abs. 2 lit. a DSGVO, sofern besondere Datenkategorien nach Art. 9 Abs. 1 DSGVO verarbeitet werden. Im Falle einer ausdrücklichen Einwilligung in die Übertragung personenbezogener Daten in Drittstaaten erfolgt die Datenverarbeitung außerdem auf Grundlage von Art. 49 Abs. 1 lit. a DSGVO.

Sofern Sie in die Speicherung von Cookies oder in den Zugriff auf Informationen in Ihr Endgerät (z. B. via Device-Fingerprinting) eingewilligt haben, erfolgt die Datenverarbeitung zusätzlich auf Grundlage von § 25 Abs. 1 TTDSG. Die Einwilligung ist jederzeit widerrufbar. Sind Ihre Daten zur Vertragserfüllung oder zur Durchführung vorvertraglicher Maßnahmen erforderlich, verarbeiten wir Ihre Daten auf Grundlage des Art. 6 Abs. 1 lit. b DSGVO.

Des Weiteren verarbeiten wir Ihre Daten, sofern diese zur Erfüllung einer rechtlichen Verpflichtung erforderlich sind auf Grundlage von Art. 6 Abs. 1 lit. c DSGVO. Die Datenverarbeitung kann ferner auf Grundlage unseres berechtigten Interesses nach Art. 6 Abs. 1 lit. f DSGVO erfolgen. Über die jeweils im Einzelfall einschlägigen Rechtsgrundlagen wird in den folgenden Absätzen dieser Datenschutzerklärung informiert.

Hinweis zur Datenweitergabe in die USA und sonstige Drittstaaten

Wir verwenden unter anderem Tools von Unternehmen mit Sitz in den USA oder sonstigen datenschutzrechtlich nicht sicheren Drittstaaten. Wenn diese Tools aktiv sind, können Ihre personenbezogenen Daten in diese Drittstaaten übertragen und dort verarbeitet werden. Wir weisen darauf hin, dass in diesen Ländern kein mit der EU vergleichbares Datenschutzniveau garantiert werden kann. Beispielsweise sind US-Unternehmen dazu verpflichtet, personenbezogene Daten an Sicherheitsbehörden herauszugeben, ohne dass Sie als Betroffener hiergegen gerichtlich vorgehen könnten. Es kann daher nicht ausgeschlossen werden, dass US-Behrden (z. B. Geheimdienste) Ihre auf US-Servern befindlichen Daten zu Überwachungszwecken verarbeiten, auswerten und dauerhaft speichern. Wir haben auf diese Verarbeitungstätigkeiten keinen Einfluss.

Widerruf Ihrer Einwilligung zur Datenverarbeitung

Viele Datenverarbeitungsvorgänge sind nur mit Ihrer ausdrücklichen Einwilligung möglich. Sie können eine bereits erteilte Einwilligung jederzeit widerrufen. Die Rechtmäßigkeit der bis zum Widerruf erfolgten Datenverarbeitung bleibt vom Widerruf unberührt.

Widerspruchsrecht gegen die Datenerfassung in besonderen Fällen sowie gegen Direktwerbung (Art. 21 DSGVO)

WERDEN DIE DATENVERARBEITUNG AUF GRUNDLAGE VON ART. 6 ABS. 1 LIT. E ODER F DSGVO ERFOLGT, HABEN SIE JEDERZEIT DAS RECHT, AUS GRÜNDEN, DIE SICH AUS IHRER BESONDEREN SITUATION ERGEBEN, GEGEN DIE VERARBEITUNG IHRER PERSONENBEZOGENEN DATEN WIDERSPRUCH EINZULEGEN; DIES GILT AUCH FÜR EIN AUF DIESE BESTIMMUNGEN GESTÜTZTES PROFILING. DIE JEWEILIGE RECHTSGRUNDLAGE, AUF DENEN EINE VERARBEITUNG BERUHT, ENTNEHMEN SIE DIESER DATENSCHUTZERKLÄRUNG. WENN SIE WIDERSPRUCH EINLEGEN, WERDEN WIR IHRE BETROFFENEN PERSONENBEZOGENEN DATEN NICHT MEHR VERARBEITEN, ES SEI DENN, WIR KÖNNEN ZWINGENDE SCHUTZWÜRDIGE GRÜNDE FÜR DIE VERARBEITUNG NACHWEISEN, DIE IHRE INTERESSEN, RECHTE UND FREIHEITEN ÜBERWIEGEN ODER DIE VERARBEITUNG DIENT DER GELTENDMACHUNG, AUSÜBUNG ODER VERTEIDIGUNG VON RECHTSANSPRÜCHEN (WIDERSPRUCH NACH ART. 21 ABS. 1 DSGVO).

WERDEN IHRE PERSONENBEZOGENEN DATEN VERARBEITET, UM DIREKTWERBUNG ZU BETREIBEN, SO HABEN SIE DAS RECHT, JEDERZEIT WIDERSPRUCH GEGEN DIE VERARBEITUNG SIE BETREFFENDER PERSONENBEZOGENER DATEN ZUM ZWECKE DERARTIGER WERBUNG EINZULEGEN; DIES GILT AUCH FÜR DAS PROFILING, SOWEIT ES MIT SOLCHER DIREKTWERBUNG IN VERBINDUNG STEHT. WENN SIE WIDERSPRECHEN, WERDEN IHRE PERSONENBEZOGENEN DATEN ANSCHLIESSEND NICHT MEHR ZUM ZWECKE DER DIREKTWERBUNG VERWENDET (WIDERSPRUCH NACH ART. 21 ABS. 2 DSGVO).

Beschwerderecht bei der zuständigen Aufsichtsbehörde

Im Falle von Verstößen gegen die DSGVO steht den Betroffenen ein Beschwerderecht bei einer Aufsichtsbehörde, insbesondere in dem Mitgliedstaat ihres gewöhnlichen Aufenthalts, ihres Arbeitsplatzes oder des Orts des mutmaßlichen Verstoßes zu. Das Beschwerderecht besteht unbeschadet anderweitiger verwaltungsrechtlicher oder gerichtlicher Rechtsbehelfe.

Recht auf Datenübertragbarkeit

Sie haben das Recht, Daten, die wir auf Grundlage Ihrer Einwilligung oder in Erfüllung eines Vertrags automatisiert verarbeiten, an sich oder an einen Dritten in einem gängigen, maschinenlesbaren Format aushändigen zu lassen. Sofern Sie die direkte Übertragung der Daten an einen anderen Verantwortlichen verlangen, erfolgt dies nur, soweit es technisch machbar ist.

SSL- bzw. TLS-Verschlüsselung

Diese Seite nutzt aus Sicherheitsgründen und zum Schutz der Übertragung vertraulicher Inhalte, wie zum Beispiel Bestellungen oder Anfragen, die Sie an uns als Seitenbetreiber senden, eine SSL- bzw. TLS-Verschlüsselung. Eine verschlüsselte Verbindung erkennen Sie daran, dass die Adresszeile des Browsers von „http://" auf „https://" wechselt und an dem Schloss-Symbol in Ihrer Browserzeile.

Wenn die SSL- bzw. TLS-Verschlüsselung aktiviert ist, können die Daten, die Sie an uns übermitteln, nicht von Dritten mitgelesen werden.

Auskunft, Löschung und Berichtigung

Sie haben im Rahmen der geltenden gesetzlichen Bestimmungen jederzeit das Recht auf unentgeltliche Auskunft über Ihre gespeicherten personenbezogenen Daten, deren Herkunft und Empfänger und den Zweck der Datenverarbeitung und ggf. ein Recht auf Berichtigung oder Löschung dieser Daten. Hierzu sowie zu weiteren Fragen zum Thema personenbezogene Daten können Sie sich jederzeit an uns wenden.

Recht auf Einschränkung der Verarbeitung

Sie haben das Recht, die Einschränkung der Verarbeitung Ihrer personenbezogenen Daten zu verlangen. Hierzu können Sie sich jederzeit an uns wenden. Das Recht auf Einschränkung der Verarbeitung besteht in folgenden Fällen:

  • Wenn Sie die Richtigkeit Ihrer bei uns gespeicherten personenbezogenen Daten bestreiten, benötigen wir in der Regel Zeit, um dies zu überprüfen. Für die Dauer der Prüfung haben Sie das Recht, die Einschränkung der Verarbeitung Ihrer personenbezogenen Daten zu verlangen.
  • Wenn die Verarbeitung Ihrer personenbezogenen Daten unrechtmäßig geschah/geschieht, können Sie statt der Löschung die Einschränkung der Datenverarbeitung verlangen.
  • Wenn wir Ihre personenbezogenen Daten nicht mehr benötigen, Sie sie jedoch zur Ausübung, Verteidigung oder Geltendmachung von Rechtsansprüchen benötigen, haben Sie das Recht, statt der Löschung die Einschränkung der Verarbeitung Ihrer personenbezogenen Daten zu verlangen.
  • Wenn Sie einen Widerspruch nach Art. 21 Abs. 1 DSGVO eingelegt haben, muss eine Abwägung zwischen Ihren und unseren Interessen vorgenommen werden. Solange noch nicht feststeht, wessen Interessen überwiegen, haben Sie das Recht, die Einschränkung der Verarbeitung Ihrer personenbezogenen Daten zu verlangen.

Wenn Sie die Verarbeitung Ihrer personenbezogenen Daten eingeschränkt haben, dürfen diese Daten – von ihrer Speicherung abgesehen – nur mit Ihrer Einwilligung oder zur Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen oder zum Schutz der Rechte einer anderen natürlichen oder juristischen Person oder aus Gründen eines wichtigen öffentlichen Interesses der Europäischen Union oder eines Mitgliedstaats verarbeitet werden.

4. Datenerfassung auf dieser Website

Server-Log-Dateien

Der Provider der Seiten erhebt und speichert automatisch Informationen in so genannten Server-Log-Dateien, die Ihr Browser automatisch an uns übermittelt. Dies sind:

  • Browsertyp und Browserversion
  • verwendetes Betriebssystem
  • Referrer URL
  • Hostname des zugreifenden Rechners
  • Uhrzeit der Serveranfrage
  • IP-Adresse

Eine Zusammenführung dieser Daten mit anderen Datenquellen wird nicht vorgenommen. Die Erfassung dieser Daten erfolgt auf Grundlage von Art. 6 Abs. 1 lit. f DSGVO. Der Websitebetreiber hat ein berechtigtes Interesse an der technisch fehlerfreien Darstellung und der Optimierung seiner Website – hierzu müssen die Server-Log-Files erfasst werden.

Kontaktformular

Wenn Sie uns per Kontaktformular Anfragen zukommen lassen, werden Ihre Angaben aus dem Anfrageformular inklusive der von Ihnen dort angegebenen Kontaktdaten zwecks Bearbeitung der Anfrage und für den Fall von Anschlussfragen bei uns gespeichert. Diese Daten geben wir nicht ohne Ihre Einwilligung weiter.

Die Verarbeitung dieser Daten erfolgt auf Grundlage von Art. 6 Abs. 1 lit. b DSGVO, sofern Ihre Anfrage mit der Erfüllung eines Vertrags zusammenhängt oder zur Durchführung vorvertraglicher Maßnahmen erforderlich ist. In allen übrigen Fällen beruht die Verarbeitung auf unserem berechtigten Interesse an der effektiven Bearbeitung der an uns gerichteten Anfragen (Art. 6 Abs. 1 lit. f DSGVO) oder auf Ihrer Einwilligung (Art. 6 Abs. 1 lit. a DSGVO), sofern diese abgefragt wurde.

Die von Ihnen im Kontaktformular eingegebenen Daten verbleiben bei uns, bis Sie uns zur Löschung auffordern, Ihre Einwilligung zur Speicherung widerrufen oder der Zweck für die Datenspeicherung entfällt (z. B. nach abgeschlossener Bearbeitung Ihrer Anfrage). Zwingende gesetzliche Bestimmungen – insbesondere Aufbewahrungsfristen – bleiben unberührt.

Anfrage per E-Mail, Telefon oder Telefax

Wenn Sie uns per E-Mail, Telefon oder Telefax kontaktieren, wird Ihre Anfrage inklusive aller daraus hervorgehenden personenbezogenen Daten (Name, Anfrage) zum Zwecke der Bearbeitung Ihres Anliegens bei uns gespeichert und verarbeitet. Diese Daten geben wir nicht ohne Ihre Einwilligung weiter.

Die Verarbeitung dieser Daten erfolgt auf Grundlage von Art. 6 Abs. 1 lit. b DSGVO, sofern Ihre Anfrage mit der Erfüllung eines Vertrags zusammenhängt oder zur Durchführung vorvertraglicher Maßnahmen erforderlich ist. In allen übrigen Fällen beruht die Verarbeitung auf unserem berechtigten Interesse an der effektiven Bearbeitung der an uns gerichteten Anfragen (Art. 6 Abs. 1 lit. f DSGVO) oder auf Ihrer Einwilligung (Art. 6 Abs. 1 lit. a DSGVO), sofern diese abgefragt wurde.

Die von Ihnen an uns per Kontaktanfragen übersandten Daten verbleiben bei uns, bis Sie uns zur Löschung auffordern, Ihre Einwilligung zur Speicherung widerrufen oder der Zweck für die Datenspeicherung entfällt (z. B. nach abgeschlossener Bearbeitung Ihres Anliegens). Zwingende gesetzliche Bestimmungen – insbesondere gesetzliche Aufbewahrungsfristen – bleiben unberührt.

5. Plugins und Tools

Google Fonts (lokales Hosting)

Diese Seite nutzt zur einheitlichen Darstellung von Schriftarten so genannte Google Fonts, die von Google bereitgestellt werden. Die Google Fonts sind lokal auf diesem Server installiert. Eine Verbindung zu Servern von Google findet dabei nicht statt.

Weitere Informationen zu Google Fonts finden Sie unter https://developers.google.com/fonts/faq und in der Datenschutzerklärung von Google: https://policies.google.com/privacy?hl=de.

Google Maps

Diese Seite nutzt über eine API den Kartendienst Google Maps. Anbieter ist die Google Ireland Limited ("Google"), Gordon House, Barrow Street, Dublin 4, Irland.

Zur Nutzung der Funktionen von Google Maps ist es notwendig, Ihre IP-Adresse zu speichern. Diese Informationen werden in der Regel an einen Server von Google in den USA übertragen und dort gespeichert. Der Anbieter dieser Seite hat keinen Einfluss auf diese Datenübertragung.

Die Nutzung von Google Maps erfolgt im Interesse einer ansprechenden Darstellung unserer Online-Angebote und an einer leichten Auffindbarkeit der von uns auf der Website angegebenen Orte. Dies stellt ein berechtigtes Interesse im Sinne von Art. 6 Abs. 1 lit. f DSGVO dar. Sofern eine entsprechende Einwilligung abgefragt wurde, erfolgt die Verarbeitung ausschließlich auf Grundlage von Art. 6 Abs. 1 lit. a DSGVO und § 25 Abs. 1 TTDSG, soweit die Einwilligung die Speicherung von Cookies oder den Zugriff auf Informationen im Endgerät des Nutzers (z. B. Device-Fingerprinting) im Sinne des TTDSG umfasst. Die Einwilligung ist jederzeit widerrufbar.

Mehr Informationen zum Umgang mit Nutzerdaten finden Sie in der Datenschutzerklärung von Google: https://policies.google.com/privacy?hl=de.

6. Eigene Dienste

Google Analytics

Diese Website nutzt Funktionen des Webanalysedienstes Google Analytics. Anbieter ist die Google Ireland Limited ("Google"), Gordon House, Barrow Street, Dublin 4, Irland.

Google Analytics ermöglicht es dem Websitebetreiber, das Verhalten der Websitebesucher zu analysieren. Hierbei erhält der Websitebetreiber verschiedene Nutzungsdaten, wie z. B. Seitenaufrufe, Verweildauer, verwendete Betriebssysteme und Herkunft des Nutzers. Diese Daten werden in einer User-ID zusammengefasst und dem jeweiligen Endgerät des Websitebesuchers zugeordnet.

Google Analytics verwendet Technologien, die die Wiedererkennung des Nutzers zum Zwecke der Analyse des Nutzerverhaltens ermöglichen (z. B. Cookies oder Device-Fingerprinting). Die von Google erfassten Informationen über die Nutzung dieser Website werden in der Regel an einen Server von Google in den USA übertragen und dort gespeichert.

Die Nutzung dieses Dienstes erfolgt auf Grundlage Ihrer Einwilligung nach Art. 6 Abs. 1 lit. a DSGVO und § 25 Abs. 1 TTDSG. Die Einwilligung ist jederzeit widerrufbar.

Die Datenübertragung in die USA wird auf die Standardvertragsklauseln der EU-Kommission gestützt. Details finden Sie hier: https://privacy.google.com/businesses/controllerterms/mccs/.

Mehr Informationen zum Umgang mit Nutzerdaten bei Google Analytics finden Sie in der Datenschutzerklärung von Google: https://support.google.com/analytics/answer/6004245?hl=de.

Google reCAPTCHA

Wir nutzen "Google reCAPTCHA" (im Folgenden "reCAPTCHA") auf dieser Website. Anbieter ist die Google Ireland Limited ("Google"), Gordon House, Barrow Street, Dublin 4, Irland.

Mit reCAPTCHA soll überprüft werden, ob die Dateneingabe auf dieser Website (z. B. in einem Kontaktformular) durch einen Menschen oder durch ein automatisiertes Programm erfolgt. Hierzu analysiert reCAPTCHA das Verhalten des Websitebesuchers anhand verschiedener Merkmale. Diese Analyse beginnt automatisch, sobald der Websitebesucher die Website betritt. Zur Analyse wertet reCAPTCHA verschiedene Informationen aus (z. B. IP-Adresse, Verweildauer des Websitebesuchers auf der Website oder vom Nutzer getätigte Mausbewegungen). Die bei der Analyse erfassten Daten werden an Google weitergeleitet.

Die reCAPTCHA-Analysen laufen vollständig im Hintergrund. Websitebesucher werden nicht darauf hingewiesen, dass eine Analyse stattfindet.

Die Speicherung und Analyse der Daten erfolgt auf Grundlage von Art. 6 Abs. 1 lit. f DSGVO. Der Websitebetreiber hat ein berechtigtes Interesse daran, seine Website vor missbräuchlicher automatisierter Ausspähung und vor SPAM zu schützen. Sofern eine entsprechende Einwilligung abgefragt wurde, erfolgt die Verarbeitung ausschließlich auf Grundlage von Art. 6 Abs. 1 lit. a DSGVO und § 25 Abs. 1 TTDSG, soweit die Einwilligung die Speicherung von Cookies oder den Zugriff auf Informationen im Endgerät des Nutzers (z. B. Device-Fingerprinting) im Sinne des TTDSG umfasst. Die Einwilligung ist jederzeit widerrufbar.

Weitere Informationen zu Google reCAPTCHA finden Sie in den Google-Datenschutzbestimmungen und den Google Nutzungsbedingungen unter folgenden Links: https://policies.google.com/privacy?hl=de und https://policies.google.com/terms?hl=de.

7. Änderungen dieser Datenschutzerklärung

Wir behalten uns vor, diese Datenschutzerklärung anzupassen, damit sie stets den aktuellen rechtlichen Anforderungen entspricht oder um Änderungen unserer Leistungen in der Datenschutzerklärung umzusetzen, z. B. bei der Einführung neuer Services. Für Ihren erneuten Besuch gilt dann die neue Datenschutzerklärung.

8. Fragen zum Datenschutz

Wenn Sie Fragen zum Datenschutz haben, schreiben Sie uns bitte eine E-Mail oder wenden Sie sich direkt an die für den Datenschutz verantwortliche Person in unserem Unternehmen:

info@pazdzewicz.de