import { Exercise } from '../types';

export const swaExercises4: Exercise[] = [
  {
    id: 'swa-3-5-moderne-architekturen-a',
    title: '3.5 - SWA - Moderne Architekturen (Teil 1)',
    parts: [
      {
        id: '3-5-a',
        prompt: 'Was kennzeichnet einen Modulith (Modularer Monolith)?',
        solution: 'Ein Modulith ist ein monolithisches System, das intern in gut strukturierte Module mit klaren Grenzen und Schnittstellen aufgeteilt ist. Es wird als eine einzige Einheit deployed, kombiniert aber die Einfachheit eines Monolithen mit besserer interner Struktur und Wartbarkeit.',
        points: 5,
        type: 'text',
      },
      {
        id: '3-5-b',
        prompt: 'Nenne drei der fünf wesentlichen Eigenschaften für „Cloud" nach NIST.',
        solution: 'Drei von fünf Eigenschaften sind:\n1. On-Demand self-service: Nutzer können Ressourcen bei Bedarf automatisch bereitstellen.\n2. Broad network access: Dienste sind über Standard-Netzwerke zugänglich.\n3. Resource pooling: Ressourcen des Anbieters werden für mehrere Kunden gebündelt.\n(Weitere: Rapid elasticity, Measured service)',
        points: 5,
        type: 'text',
      },
      {
        id: '3-5-c',
        prompt: 'Beschreiben Sie das "Conway\'s Law" und erklären Sie, warum es bei Microservices-Architekturen besonders relevant ist.',
        solution: 'Conway\'s Law besagt, dass die Architektur eines Systems die Kommunikationsstruktur der entwickelnden Organisation widerspiegelt. Bei Microservices ist dies relevant, weil es nahelegt, Teams entsprechend der Service-Grenzen zu organisieren ("Inverse Conway Maneuver"), um autonome Teams zu fördern, die für ihre jeweiligen Services End-to-End verantwortlich sind.',
        points: 6,
        type: 'text',
      },
      {
        id: '3-5-d',
        prompt: 'Ein E-Commerce-Unternehmen möchte sein monolithisches System modernisieren. Welche Vor- und Nachteile haben die Ansätze Modulith und Microservices in diesem Kontext?',
        solution: 'Modulith:\n(+) Geringere Betriebskomplexität, einfachere Transaktionen, schrittweises Refactoring.\n(-) Gemeinsame Release-Zyklen, begrenzte technologische Freiheit.\n\nMicroservices:\n(+) Unabhängige Entwicklung & Deployment, bessere Skalierbarkeit, technologische Freiheit.\n(-) Höhere Komplexität (verteiltes System), aufwändigere Infrastruktur, Herausforderungen bei Datenkonsistenz.',
        points: 7,
        type: 'text',
      }
    ],
    explanation: '### Lösungserklärung\n\n**Modulith**: Ein Kompromiss zwischen Monolith und Microservices. Er behält den einfachen Betrieb eines Monolithen bei, erzwingt aber eine saubere, modulare Innenstruktur, was die Wartbarkeit verbessert.\n\n**Cloud-Eigenschaften (NIST)**: Die fünf Merkmale (On-demand self-service, Broad network access, Resource pooling, Rapid elasticity, Measured service) definieren, was einen echten Cloud-Service von traditionellem Hosting unterscheidet.\n\n**Conway\'s Law**: Stellt einen Zusammenhang zwischen Organisations- und Systemstruktur her. Für Microservices wird es oft umgekehrt genutzt (**Inverse Conway Maneuver**): Man gestaltet die Organisation (kleine, autonome Teams), damit die gewünschte Architektur (kleine, unabhängige Services) entsteht.\n\n### Quellen\n*Folien 3.5, Seite 4-39*'
  },
  {
    id: 'swa-3-5-moderne-architekturen-b',
    title: '3.5 - SWA - Moderne Architekturen (Teil 2)',
    parts: [
      {
        id: '3-5-e',
        prompt: 'Erläutern Sie zwei der vier vorgestellten Resilienz-Patterns (Timeouts, Bulkheads, Fallbacks, Circuit Breaker).',
        solution: '1. Timeouts: Kapselt Aufrufe mit einer maximalen Wartezeit, um zu verhindern, dass ein langsamer Service das ganze System blockiert ("Fail fast").\n2. Circuit Breaker: Stoppt nach einer bestimmten Anzahl von Fehlern weitere Aufrufe an einen gestörten Dienst, um diesem Zeit zur Erholung zu geben und Kaskadenausfälle zu vermeiden. Nach einer Wartezeit wird der Zustand geprüft (halb-offen).',
        points: 6,
        type: 'text',
      },
      {
        id: '3-5-f',
        prompt: 'Welche Probleme kann es bei einer Migration eines Monolithen zu Microservices geben? Nennen Sie zwei.',
        solution: '1. Falscher Service-Schnitt: Ein ungeeigneter Schnitt führt zu stark gekoppelten Services ("verteilter Monolith"), was die Komplexität erhöht, anstatt sie zu reduzieren.\n2. Datenabhängigkeiten: Die Aufteilung einer gemeinsamen Datenbank in separate Datenbanken pro Service ist extrem komplex und birgt Risiken für die Datenkonsistenz (Stichwort: verteilte Transaktionen).',
        points: 6,
        type: 'text',
      },
      {
        id: '3-5-g',
        prompt: 'Entwerfen Sie eine Event-getriebene Architektur (EDA) für einen Online-Buchungsservice. Definieren Sie zwei Komponenten und zwei nötige Events für die Kommunikation.',
        solution: 'Komponenten:\n1. BookingService: Verwaltet Buchungen.\n2. PaymentService: Wickelt Zahlungen ab.\n\nEvents:\n1. BookingCreatedEvent: Ausgelöst vom BookingService, um den Zahlungsprozess im PaymentService zu initiieren.\n2. PaymentCompletedEvent: Ausgelöst vom PaymentService, um den BookingService zu informieren, dass die Buchung nun bestätigt werden kann.',
        points: 7,
        type: 'text',
      }
    ],
    explanation: '### Lösungserklärung\n\n**Resilienz-Patterns**: In verteilten Systemen sind Teilausfälle normal. Patterns wie **Timeouts** (verhindern ewiges Warten) und **Circuit Breakers** (schützen vor Überlastung gestörter Dienste) sind essenziell, um die Stabilität des Gesamtsystems zu gewährleisten.\n\n**Migration zum Microservice**: Eine "Big Bang"-Migration ist extrem riskant. Ein evolutionärer Ansatz ist besser. Die größten **Probleme** bei der Migration sind oft das Finden der richtigen Service-Grenzen (Schnitt) und der Umgang mit der gemeinsamen Datenbank.\n\n**EDA**: Eine Event-getriebene Architektur entkoppelt Komponenten stark voneinander. Ein Service sendet ein **Event** (z.B. "Buchung erstellt"), andere Services reagieren darauf. Dies erhöht die Resilienz und Skalierbarkeit.\n\n### Quellen\n*Folien 3.5, Seite 4-39*'
  }
];