Warum es wichtig ist, die Kernel-Versionen der Plattform zu überwachen

Was ist der „Kern der Plattform“ und warum sind die Versionen kritisch

Unter „Kern“ versteht man Domains, in denen Fehler nicht vergeben werden: Wallet und Ledger, Wetten/Runden, Kasse (Einzahlungen/Auszahlungen), Identifikation (KYC/AML/RG), Verträge mit Spieleanbietern und Abrechnung/Reporting.

Jede Aktualisierung hier wirkt sich auf Geld, Regulierung und Vertrauen aus. Kernel-Versionen sind daher keine „Nummer im Paket“. json", sondern ein Instrument des Change und Responsibility Managements.

Warum Versionen nachverfolgen

1. Steuerung des Geldrisikos. Wir wissen genau, welcher Code für welche Runde/Auszahlung berechnet wurde - beseitigt Streitigkeiten und beschleunigt die Analyse von Vorfällen.

2. Kompatibilität der Integrationen. Spiele-/Zahlungsanbieter sind an Verträge gebunden. Version = Garant dafür, dass Felder, Status und Geschäftsregeln übereinstimmen.

3. Compliance und Audit. Der Regler fordert Reproduzierbarkeit: „welches Build, welches Schema, welche Steuerung“. Die Version ist ein Anker der Beweisgrundlage.

4. Schnelle Releases ohne Downtime. Die Versionierung ermöglicht die Freigabe kompatibler Änderungen und das Ausrollen kanarisch.

5. Incident Management. Rollback/Roll-forward ist einfach, wenn es markierte Artefakte, Migrationen und eine Kompatibilitätsmatrix gibt.

6. Transparenz für die Produktteams. Wenn „der Vertrag bis X.Y stabil ist“, planen die Fronten/Marketing/Analytik ohne Überraschungen.

Versionsrichtlinie (SemVer für Kernel)

Wir verwenden SemVer 'MAJOR. MINOR. PATCH'+ „Schemarevision“ und „Ereignisvertragsversion“:

PATCH (x.y. Z) - Korrekturen ohne Änderung der API/Schemata/Berechnungslogik. Rollout ist schnell, Rollback trivial.
MINOR (x.Y.z) - kompatible Erweiterungen: neue Felder „nullable“, neue Events, Flags. „Expand-only“ -Migrationen.
MAJOR (X.y. z) - brechende Änderungen: Entfernung von Feldern/Ereignissen, Änderung der Berechnungsregeln, neue Invarianten des Ledgers.

Zusätzlich erfassen wir:

„schemaVer“ (DB/Ledger/Verzeichnisse), „contractVer“ (Busereignisse und Webhooks), „calcVer“ (Berechnungs-/Bonusregel-Engine).

💡 Regel: eine Richtung in der Freigabe. Entweder „wir erweitern ohne zu brechen“ oder „wir brechen mit Schatten“. Vermischung ist der Weg zu Vorfällen.

Verträge und Abwärtskompatibilität

Verträge für externe und interne Verbraucher

API/Webhooks/Events: Wir versionieren die URL ('/v2/...'), den Header ('X-Contract-Version'), das' schemaVer '-Feld in der Payload.

Ereignisse im Bus: Feld 'eventVer', Silent-Breaking-Verbot (Änderungen der Feldart, Bedeutung der Zustände).

DB: Migrationen im Stil von Expand → Migrate → Contract.

Sie können hinzufügen, ändern - vorsichtig, entfernen - mit „Schatten“

Das Hinzufügen von Feldern ist nur nullable/c Standard.

Sinnwechsel - nur in MAJOR mit paralleler Veröffentlichung des „alten“ Feldes ('_ legacy') für eine Übergangszeit.

Löschung - nach Deprecate und Telemetrie „wer liest noch das Alte“.

Schema- und Datenmigrationen

Expand: Fügen Sie eine Spalte/einen Index hinzu, geben Sie ein neues Ereignis ein - ohne die vorhandenen Leser zu berühren.

Migrieren: Werte im Hintergrund (Batch/Online) ausfüllen/neu berechnen, Doppeleintrag (Dual-Write) an neuer Stelle einfügen.

Vertrag: Leser übersetzen, Legacy-Thread im nächsten MAJOR entfernen.

Tools: Migrationen unter Feature-Flag, Shadow-Tabellen, Online-DDL, Invarianten auf DB-Ebene (Check-Constraints) und Domain.

Versionierung von Berechnungen: Geld, Wetten, Boni

Separat fixieren Sie „calcVer“ - die Version der Logik der Geldberechnung (Wette/halten/settle/VOID, Regeln für Boni und Wetten).

In jeder 'Runde. settled`, `payout. completed`, `bonus. issued 'schreiben' calcVer'.

Bei einem Streit können Sie die Berechnung genau mit der Logik reproduzieren, die zum Zeitpunkt des Ereignisses galt.

Umschaltung ' calcVer ' machen Sie kanarejetschno nach dem Prozent des Verkehres/Region/Kategorie der Spiele.

Observability für Versionsfähigkeit

Tags im Trace: 'buildId', 'gitSha', 'semver', 'schemaVer', 'contractVer', 'calcVer' in allen kritischen Spans (Wette, settle, Auszahlung).

Dashboards nach Versionen: Fehler, Latenz, Fin-Deltas im Versionsschnitt.

Alertas auf „Versionsdrift“: Wenn ein Teil der Busverbraucher das falsche Schema liest.

Sicherheit und Compliance

Versionierte Artefakte (Bilder, Migrationen) signiert; werden in einer unveränderlichen Registry/Bucket gespeichert.

DR/Audit: Es ist möglich, die Umgebung „wie am Tag T“ anzuheben (Image, Migrationen zur Version, DB-Snapshots).

Revisionen von AML/RG/KYT-Regeln sind auch Versionen (policyVer) und Protokolle ihrer Anwendung.

Freigabeverfahren

1. Revue-Vertrag: Änderungsliste mit dem Vermerk „PATCH/MINOR/MAJOR“, Auswirkungen auf externe/interne Verbraucher.

2. Backwards-Compat-Tests: Prüfungen an alten Kunden/Ereignissen (Vertragstests).

3. Kanarische Rollout: 1-5% des Verkehrs; Metriken für p95, Fehler, finanzielle Diskrepanzen.

4. Die Telemetrie der Legacy-Nutzung: Wer noch „v1“ hört, welche Felder gelesen werden - der Deprecate-Plan.

5. Komma-Paket: Was ändert sich, wenn End-of-Life alte Versionen, wie zu migrieren.

Typische Kompatibilitätsmatrizen (Beispiel)

Komponente	Client (min. Version)	Der Server	Der Zustand
`wallet-api`	1. 7	2. 3	OK (MINOR)
`bets-webhook`	1. 4	2. 0	OK, legacy-Feld 'odds _ legacy' vor 2026-01-31
`ledger-schema`	–	3. 1	Erfordert eine' expand '-Migration vor Release 3. 2
`events. contract`	1. x	2. x	Dual-Publish vor dem Ausschalten von 'v1'

Beispiele für Verträge

Busereignis mit Version:

json
{
"event": "round. settled",  "eventVer": "2. 4",  "schemaVer": "ledger-3. 1",  "calcVer": "wallet-7. 2",  "roundId": "R-2025-10-17-PRAGM-12",  "bets": [{"betId":"b_9f2","stake":"5. 00","payout":"180. 00","outcome":"WIN"}],  "ts": "2025-10-17T14:23:12. 031Z",  "traceId": "tr_5f1"
}

REST mit Vertragsversion:


GET /v2/wallet/balance
X-Contract-Version: 2. 3

Anti-Muster

„Stille“ Änderungen: Ändern Sie die Art/Bedeutung der Felder ohne MAJOR und Deprecate.

Mischen Sie Datenmigration und Geldlogik in einem Release ohne Dual-Write.

Globale Flags statt Versionen (kann nicht wiederhergestellt werden, „was dann funktionierte“).

Keine Vertragstests und kein Katalog von Regelungen.

Löschen Sie Legacy ohne Telemetrie-Nutzung - Partner/Dashboards brechen.

Eine einzelne Zahl „irgendwo im Wiki“ ohne Artefakte/Signaturen - nicht reproduzierbar.

Checkliste Kernel Versionsdisziplin

Standards

Versionsfamilie: 'semver', 'schemaVer', 'contractVer', 'calcVer', 'policyVer'.
Daten-/Schema-Katalog (Datenkatalog) mit Historie und Besitzern.

Verträge

Versionierte Endpunkte/Ereignisse, Header/Versionsfeld.
Deprecation-Verfahren mit Terminen und Nutzungstelemetrie.

Migrationen

Expand→Migrate→Contract, dual-write, онлайн-DDL.
Shadow-Tabellen und Invarianten auf DB-Ebene.

Releases

Kanarische Rollout, Kompatibilitätsmatrix, Rollback-Plan.
Signierte Bilder/Migrationen, unveränderliche Artefakte.

Observability

Versionskennzeichen in Trace/Logs/Metriken.
Fehler/Latenz/Fin-Delta Dashboards nach Version.

Compliance/DR

Reproduzierbarer Anstieg der Umgebung „am Datum T“.
policyVer-Anwendungsprotokolle (AML/RG/KYT).

Die Versionsfähigkeit des Kerns ist die „Versicherung“ des Geldes und das Tempo der Produktentwicklung. Mit ihr entwickelt sich die Plattform vorhersehbar weiter: Neue Möglichkeiten kommen ohne Pannen heraus, Finanzen bleiben reproduzierbar, Integrationen sind kompatibel, Audits sind ruhig. Machen Sie die Versionen zu einem Teil des Prozesses (Verträge, Migrationen, Telemetrie, Releases) - und Ihr Backend wird jahrelange Änderungen ohne Verluste für P&L und Reputation überstehen.