Kapitel 89

gRPC und Protobuf für interne Java Services

gRPC für interne Service-zu-Service-Kommunikation: Contracts, Streaming, Deadlines, Backward Compatibility und Observability.

gRPCProtobufInternal APIsDeadlines

Warum dieses Thema in Version 5 wichtig ist

Version 5 behandelt gRPC und Protobuf für interne Java Services als Senior-Thema. In echten Enterprise-Projekten reicht es nicht, eine Bibliothek einzubauen oder ein Pattern zu kennen. Entscheidend ist, ob die Lösung fachlich begründet, testbar, betreibbar, sicher und langfristig änderbar bleibt.

gRPC und Protobuf für interne Java Services - kompakte fachliche SVG-Darstellung
gRPC und Protobuf für interne Java Services - kompakte fachliche SVG-Darstellung

Orientierungsrahmen

AspektErklärung
AusgangspunktDas Thema wird als Teil einer produktionsreifen Java-Enterprise-Landschaft betrachtet, nicht als isolierte Technik.
KernfrageWelche fachliche Grenze, Betriebsgrenze oder Integrationsgrenze wird durch gRPC und Protobuf für interne Java Services sichtbar?
RisikoScheinbar technische Details erzeugen oft fachliche Nebenwirkungen: Datenverlust, Dopplungen, unklare Ownership, Sicherheitslücken oder hohe Betriebskosten.
NachweisADR, Test, Runbook, Metrik, Trace, Contract, SBOM oder Code-Kommentar muss zeigen, dass die Entscheidung verstanden wurde.
1. EntscheidungsgrenzeWas darf das Team frei entscheiden, was braucht Governance?
2. LaufzeitgrenzeWelche Annahme muss im Betrieb messbar bleiben?
3. Daten-/EventgrenzeWelche Daten werden kopiert, versioniert oder gelöscht?
4. SicherheitsgrenzeWelche Identität, Rolle, Policy oder Zertifikatskette wirkt hier?
5. QualitätsgrenzeWelche Tests schützen die Entscheidung gegen schleichende Erosion?
6. Kosten-/BetriebsgrenzeWelche Kosten, Limits oder Runbooks gehören zum Thema?

Technisches Beispiel

Das Beispiel zeigt absichtlich keine Framework-Magie. Die Regel wird als Java-Objekt formuliert. Dadurch kann sie in Spring Boot, Jakarta EE, Quarkus oder Micronaut verwendet und mit Unit-Tests abgesichert werden.

gRPC und Protobuf für interne Java Services - Policy Object
package at.aydinsude.enterprise.v5.sketch;

import java.time.Instant;
import java.util.List;
import java.util.Map;

// Pattern: Policy Object - kapselt eine wiederverwendbare Architekturregel.
// Pattern: Strategy - unterschiedliche Projektsituationen können andere Bewertungen liefern.
public final class GrpcContractPolicy {
    public ArchitectureDecision evaluate(ArchitectureContext context) {
        int risk = context.businessCriticality() + context.integrationCount() + context.operationalComplexity();
        String action = risk >= 9 ? "formal-review" : risk >= 5 ? "lightweight-adr" : "team-standard";
        return new ArchitectureDecision(action, risk, Instant.now(), List.of(
                "document trade-offs",
                "add automated evidence",
                "define rollback or recovery path"));
    }

    public record ArchitectureContext(int businessCriticality, int integrationCount, int operationalComplexity, Map<String, String> tags) {}
    public record ArchitectureDecision(String action, int riskScore, Instant decidedAt, List<String> evidence) {}
}

Die gleiche Entscheidung muss im Projekt sichtbar bleiben. Eine kleine YAML- oder Markdown-Dokumentation hilft, Standards zu automatisieren und Ausnahmen sauber zu erklären.

Governance-/Evidence-Skizze
# grpc-und-protobuf-fuer-interne-java-services.yaml
owner: enterprise-architecture
chapter: 89
risk_level: senior
evidence_required:
  - adr
  - architecture-test
  - runbook
  - monitoring-dashboard
review:
  cadence: quarterly
  escalation: architecture-board

Typische Fehlerbilder

Fehler 1: Das Thema wird nur technisch gelöst. Fachliche Auswirkungen, Wiederanlauf, Security und Ownership bleiben unklar.
Fehler 2: Teams bauen Sonderlösungen ohne gemeinsame Standards. Dadurch entstehen mehr Betriebsvarianten als notwendig.
Fehler 3: Es gibt keine Nachweise. Bei Incident, Audit, Upgrade oder Migration muss später geraten werden.

Prüffragen für Senior Entwickler

  • Welche Entscheidung wird hier wirklich getroffen?
  • Welche Alternative wurde bewusst verworfen?
  • Welche Metrik zeigt im Betrieb, ob die Annahme noch stimmt?
  • Welche Tests verhindern Rückfälle?
  • Welche Dokumentation muss im Repository liegen?
  • Welche Auswirkung hat das Thema auf Legacy-Migration, OpenShift-Betrieb und Kosten?

Merksatz

Grundregel: gRPC und Protobuf für interne Java Services ist erst Enterprise-ready, wenn Code, Contract, Betrieb, Security, Kosten und Nachweis zusammenpassen.
⌂ Cockpit