Dies ist eine Fortsetzung des Blog-Posts Fehlerbehandlung für Kafka Consumer mit Retries, mit seitdem gewonnenen Erkenntnissen.
Redet man über Mitbestimmung der Mitarbeiter:innen in einer Firma, kommt irgendwann zwangsläufig das Thema Transparente Gehälter: Wer darf die Gehälter einsehen, und wer soll darüber entscheiden?
Kafka offers two cleanup policies, which seems simple enough: “delete”, where data is deleted after a certain amount of time, and “compact”, where only the most recent value is kept for any key. But what if data is not deleted/compacted as expected?
Murphy’s Law sagt: “Anything that can go wrong will go wrong” - wenn auf etwas Verlass ist, dann auf den Fehlerteufel. Deshalb schauen wir uns an, wie wir in den Kafka-Consumern die Event-Verarbeitung mit Retries robuster bauen können. Wir benutzen im Projekt Kafka mit Kotlin und spring-kafka, die grundlegenden Konzepte lassen sich aber auch auf andere Systeme übertragen.
Fragestellungen aus der Praxis mit Git, die zunächst verwirren, aber doch relativ leicht zu lösen sind… wenn man weiß wie.
Oha, dieses Projekt haben wir lange nicht angefasst. Die benutzten Bibliotheken hängen voller Spinnweben, und auch die Programmiersprachenversion war schon vor einem Jahr nicht mehr aktuell. Bevor ich loslegen kann, muss hier erst einmal aufgeräumt werden… Über Sicherheitslücken in den alten Bibliotheken will ich gar nicht nachdenken.