Warum der Preis auf Ihrem Bild veraltet ist

Der Preis wird am Dienstag um 10:03 Uhr gesenkt. In der Maklersoftware ist das ein Feld, im Portal eine Minute später eine neue Zahl. Der Instagram-Post von vor drei Wochen zeigt den alten Preis. Die Link-Vorschau, die Facebook beim ersten Teilen zwischengespeichert hat, zeigt ihn auch. Der Aushang im Schaufenster sowieso.

Niemand hat einen Fehler gemacht. Die Grafik war richtig, als sie entstand.

Ein Bild ist eine Momentaufnahme

Das ist der Kern, und er ist unbequem: Eine Grafik ist der Zustand eines Datensatzes zu dem Zeitpunkt, an dem jemand auf „Erzeugen“ geklickt hat. Der Datensatz lebt weiter. Preise werden gesenkt, Objekte reserviert, ein besseres Foto kommt vom Fotografen, die Wohnfläche wird nach dem Aufmaß korrigiert. Jede dieser Änderungen landet dort, wo die Daten liegen. Keine davon landet im Bild.

Die Gründe sind nicht Nachlässigkeit, sondern Struktur:

1. Das Bild liegt in einem anderen Werkzeug als der Preis. Die Maklersoftware kennt den Preis, das Grafikwerkzeug kennt die Grafik, und keins der beiden weiß vom anderen. Die Änderung müsste ein Mensch hinübertragen, und dieser Mensch hat gerade den Preis gesenkt und drei Interessenten anzurufen.
2. Neu erzeugen kostet. Bei den meisten Werkzeugen der Kategorie kostet jedes Bild Geld oder ein Kontingent. „Nochmal rendern? Der Preis hat sich doch nur um zehntausend geändert“ — den Satz haben wir schon einmal zitiert, er fällt in jedem Büro.
3. Niemand sieht es. Das teure Bild ist nicht das falsche, sondern das falsche, das niemand mehr ansieht. Der Post ist drei Wochen alt, die Vorschau steckt in einem fremden Cache. Wer prüft die?

Der Schaden ist konkreter, als er klingt. Ein Interessent, der auf der Grafik 685.000 € sieht und im Exposé 679.000 €, hält eine der beiden Zahlen für falsch — und er weiß nicht, welche. Der günstigere Preis, für den die Senkung ja gedacht war, erreicht ihn nicht. Und je nach Fall ist der alte Preis auf einer Werbegrafik nicht nur unschön, sondern irreführende Werbung.

Die Richtung umkehren

Der übliche Weg ist: Bilder bestellen. Man gibt Daten hinein und bekommt Grafiken zurück, einmal. Wer sie aktuell halten will, bestellt neu.

Ein beobachteter Bestand kehrt die Richtung um. Man bestellt keine Bilder, man hinterlegt eine Adresse — die CSV-Datei, die die Maklersoftware oder der Shop ohnehin exportiert — und einen Abstand. Ab dann passiert dreierlei, ohne dass jemand daran denkt:

• Holen. In dem Abstand wird die Datei abgefragt. Die Anfrage trägt den Validator der letzten Antwort mit, und ein Server, der die Datei seither nicht geändert hat, antwortet mit „unverändert“ statt mit der Datei. Dann wird nichts geladen, nichts verglichen, nichts gesetzt.
• Vergleichen. Kommt eine neue Datei, wird sie Zeile für Zeile an der Objektnummer mit dem letzten Stand verglichen. Eine Zeile ist neu, geändert, verschwunden oder gleich — und bei „geändert“ steht dabei, welches Feld.
• Nur das Geänderte setzen. Für jede neue oder geänderte Zeile werden die Grafiken in den gewählten Formaten neu gesetzt. Für die gleichen Zeilen passiert nichts. Eine verschwundene Zeile gilt als entfernt und behält ihre letzte Grafik; ein verkauftes Haus ist kein Fehler.

Was jede Prüfung getan hat, steht in einem Änderungsdokument, das man abrufen kann, und auf Wunsch kommt es als Webhook. Es sieht so aus — das hier ist ein echtes aus unserem Betrieb, gekürzt auf die Felder, um die es geht:

{
  "at": "2026-09-09T11:08:45.755Z",
  "status": "ok",
  "added": 0,
  "changed": 1,
  "retired": 0,
  "unchanged": 2,
  "charged_cents": 0,
  "rows": [
    {
      "key": "H-1077",
      "change": "changed",
      "fields": ["price"],
      "data": { "title": "Altbauwohnung mit Fischgrätparkett", "price": "679.000 €" }
    }
  ]
}

Drei Zeilen im Bestand, eine geändert, das Feld heißt „price“, berechnet wurde nichts. Wer eine Maklersoftware betreibt, kann so ein Dokument verarbeiten; wer keine betreibt, kann es lesen.

Fünf Tage Betrieb

Wir betreiben seit dem 4. September zwei Demo-Bestände gegen unsere eigene Prüfung: drei Immobilien und drei Produkte, jeweils alle 15 Minuten geholt. Die Dateien ändern sich nach der Uhr, damit man der Beobachtung bei der Arbeit zusehen kann: Die Altbauwohnung wird in jeder ungeraden Stunde um 6.000 Euro günstiger und in der geraden wieder teurer, der Sneaker bekommt in ungeraden Stunden einen Aktionspreis, und der Rasenmäher verschwindet in der letzten Viertelstunde jeder Stunde aus dem Sortiment und kommt zurück.

Stand 9. September, 11:23 Uhr UTC, aus der Datenbank gelesen, nicht geschätzt:

	Immobilien	Produkte
Prüfungen	467	467
davon „unverändert“ (nichts geladen)	348	231
davon mit Änderungen	118	235
erkannte Zeilenänderungen	117	234
Zeilen entfernt und zurückgekehrt	—	117
fehlgeschlagene Prüfungen	1	1
berechnet	50 €	50 €

Die eine fehlgeschlagene Prüfung je Bestand stammt vom 7. September, 3:03 Uhr UTC: Der Server, auf dem die Demo-Dateien liegen, hat neu gestartet, und die Prüfung hat ihn genau in dieser Minute erwischt. Sie hat nichts angefasst — keine Zeile verändert, keine Grafik gelöscht — und es 60 Minuten später wieder versucht. Da war alles da.

Berechnet wurden 50 € je Bestand, einmal, mit der ersten Prüfung im September. Nicht je Prüfung, nicht je Änderung, nicht je Grafik. Ein Bestand, dessen Preis sich 117-mal ändert, kostet dasselbe wie einer, dessen Preis sich nie ändert; der Unterschied ist nur, dass beim ersten die Grafiken 117-mal folgen.

Sollten.

Was wir beim Schreiben gefunden haben

Für die Tabelle oben haben wir die Datenbank gefragt, und eine Zahl passte nicht: 117 erkannte Preisänderungen, zwölf Renderings. Alle zwölf in der ersten halben Stunde nach dem Anschließen. Danach hat jede Prüfung die Änderung korrekt erkannt, korrekt ins Änderungsdokument geschrieben — und die Grafiken standen still. Vier Tage lang zeigte die Grafik der Altbauwohnung in jeder geraden Stunde einen Preis, den die Datei nicht mehr hatte.

Die Ursache ist die Art Fehler, die man nur mit echten Daten findet. Jede Änderung erzeugt Aufträge, die Grafik neu zu setzen, und damit ein Auftrag nicht doppelt läuft, wenn dieselbe Prüfung wiederholt wird, trug jeder Auftrag einen Schlüssel: Bestand, Objektnummer, Format — und den Inhalt der Zeile. Ein Preis, der auf einen früheren Wert zurückkehrt, hat denselben Inhalt wie damals. Der Auftrag mit diesem Schlüssel war vier Tage alt und längst erledigt. Die Warteschlange hat ihn zurückgegeben, wie sie soll, und niemand hat etwas gesetzt.

Unsere Demo-Bestände pendeln zwischen zwei Werten, das ist der Fall, der diesen Fehler am zuverlässigsten versteckt. Aber er ist kein Demo-Fall. Ein Aktionspreis, der endet, ist genau das: Der Preis kehrt auf den Wert zurück, den die Grafik vor der Aktion zeigte. Mit dem alten Schlüssel wäre die Aktionsgrafik für immer stehen geblieben.

Seit dem 9. September trägt der Auftrag die Kennung der Prüfung statt des Inhalts. Eine Prüfung, die eine Zeile als geändert erkennt, setzt sie neu, gleich wie die Zeile im letzten Monat aussah; nur die Wiederholung derselben Prüfung bleibt ein einziger Auftrag. Der Test dafür lässt einen Preis auf seinen ersten Wert zurückfallen und dann wieder auf den zweiten und erwartet beide Male eine neue Grafik. Mit dem alten Schlüssel wird er beim ersten Rückfall rot; wir haben das nachgesehen, bevor wir ihn behalten haben.

Die erste Prüfung nach der Auslieferung lief am 9. September um 12:08:50 Uhr UTC und fand die Altbauwohnung geändert. Um 12:08:56 waren alle drei Grafiken neu gesetzt, und die Zeile kannte ihre neuen Bilder. Sechs Sekunden von „erkannt“ bis „gesetzt“, nach vier Tagen Stillstand.

Wir hätten den Fehler auch ohne diesen Beitrag gefunden, aber später, und vermutlich durch einen Kunden. Ein beobachteter Bestand verspricht etwas, das man nicht am Bild sehen kann: dass es sich ändert, wenn es soll. Das einzige ehrliche Maß dafür ist das Änderungsdokument neben der Liste der Renderings, und die beiden müssen übereinstimmen. Jetzt tun sie es, und es gibt einen Test, der es merkt, wenn sie es nicht mehr tun.

Was Sie prüfen sollten, bei uns wie bei anderen

Wenn ein Werkzeug verspricht, Grafiken aktuell zu halten, sind das die Fragen, die den Unterschied zwischen einem Versprechen und einem Mechanismus ausmachen:

1. Woran erkennt es ein Objekt? Wenn die Antwort „an der Zeile“ oder „am Titel“ lautet, wird jede Preisänderung zu einem neuen Objekt und das alte bleibt stehen. Es muss die Objektnummer sein — die, die Ihre Software vergibt.
2. Was passiert bei „unverändert“? Wenn jede Prüfung die ganze Datei lädt und alles neu setzt, zahlen Sie für Stillstand und bekommen bei jedem Durchlauf neue Bildadressen, die Sie nirgends eingetragen haben.
3. Was passiert bei einem Ausfall Ihres Servers? Die richtige Antwort ist: nichts. Keine Löschung, kein Neuaufbau, ein Hinweis, und ein Versuch später.
4. Setzt es eine Grafik neu, wenn ein Preis auf einen früheren Wert zurückkehrt? Wir haben das vier Tage lang nicht getan. Fragen Sie danach.
5. Wo steht, was passiert ist? Ein Änderungsdokument je Prüfung, das Zeile und Feld nennt. Ohne das können Sie die Antworten auf die Fragen eins bis vier nicht überprüfen — und wir auch nicht.

Die letzte Frage ist die, an der wir unseren eigenen Fehler gefunden haben. Das ist kein Zufall. Ein System, das aufschreibt, was es getan hat, kann gegen das geprüft werden, was es hätte tun sollen. Eines, das nur Bilder liefert, kann das nicht.