Der Erscheinungskalender von My Comics Collection wird jeden Morgen um 9 Uhr Pariser Zeit über einen externen Cron-Job aktualisiert, der die öffentliche API von Metron.cloud (Lizenz CC-BY-SA 4.0) abfragt. Das System synchronisiert neue Solicitations, aktualisiert geänderte Daten, lädt fehlende Cover in einen lokalen Disk-Cache herunter und benachrichtigt intern die Abonnenten, deren Pull List betroffen ist.
Der Erscheinungskalender basiert auf einer Architektur mit 4 technischen Schichten. Schicht 1: Metron.cloud, die ursprüngliche Datenquelle, eine gemeinschaftlich betriebene Datenbank, die 2018 gegründet wurde und die offiziellen Solicitations der Verlage unter der Lizenz CC-BY-SA 4.0 aggregiert. Schicht 2: ein externer Cron-Job, gehostet auf cron-job.org (kostenloser Dienst mit 30-Sekunden-Timeout), der jeden Morgen um 9:00 Uhr Pariser Zeit einen dedizierten Endpunkt der My-Comics-Collection-API aufruft. Schicht 3: die Server-API, die die neuen Metron-Daten über deren REST-API abruft, die MySQL-Tabelle upcoming_releases aktualisiert und den asynchronen Download fehlender Cover auslöst. Schicht 4: das Frontend der Anwendung, das diese Tabelle bei jedem Nutzerbesuch abfragt, um den aktuellen Kalender anzuzeigen.
Die Systemarchitektur: Metron → API → Cache → Nutzer
Dieses 4-Schichten-Design trennt die Zuständigkeiten sauber voneinander: Metron verwaltet die Quelldaten (die wir im Rahmen ihrer Lizenz legal nutzen), der Cron-Job steuert die Frequenz (wir kontrollieren, wann synchronisiert wird), der Server übernimmt die Persistenz (MySQL- und Disk-Cache), und das Frontend übernimmt die Darstellung. Fällt eine der Schichten vorübergehend aus, laufen die anderen weiter: der MySQL-Cache behält die zuvor abgerufenen Daten auch dann, wenn Metron nicht erreichbar ist, wodurch leere Seiten vermieden werden.
Der tägliche Cron-Job: warum 9 Uhr Pariser Zeit
Die Wahl der Uhrzeit 9:00 Uhr Pariser Zeit (UTC+1 bzw. im Sommer UTC+2) folgt mehreren betrieblichen Überlegungen. (1) Zeitverschiebung zu den USA: 9:00 Uhr Paris entspricht 3-4 Uhr New Yorker Zeit, also dem Zeitpunkt, zu dem die amerikanischen Verlage ihre nächtlichen Aktualisierungen der Metron-Datenbank abgeschlossen haben. Zu dieser Uhrzeit sind die Metron-Daten frisch und für die kommenden 24 Stunden stabil. (2) Geringe Serverlast: 9 Uhr Pariser Zeit liegt für die meisten Nutzer von My Comics Collection noch in einer ruhigen Phase, wodurch der Cron-Job nicht mit dem Spitzennutzertraffic konkurriert. (3) Verfügbarkeit für den Tag: Französischsprachige Nutzer, die die Anwendung früh am Tag (8-11 Uhr) öffnen, sehen einen frisch aktualisierten Kalender, was die wahrgenommene Qualität maximiert.
Eine Ausnahme: Für Nutzer im asiatisch-pazifischen Raum, die um Mitternacht Pariser Zeit (bei ihnen Morgen) auf die Seite zugreifen, kann der Kalender bis zur Synchronisation um 9 Uhr noch Daten vom Vortag anzeigen. Das ist ein bewusster Kompromiss: Es wird für die frankophone EU-Mehrheit optimiert, nicht für die APAC-Minderheit.
Der 30-Sekunden-Timeout und die asynchrone Fire-and-Forget-Architektur
Eine technische Einschränkung des kostenlosen Dienstes cron-job.org ist der HTTP-Timeout von 30 Sekunden. Braucht der Server von My Comics Collection länger als 30 Sekunden für die Antwort, wertet cron-job.org dies als Fehler und sendet eine Fehlerbenachrichtigung. Die vollständige Metron-Synchronisation (Abruf der 400+ Solicitations, MySQL-Update, Download neuer Cover) dauert jedoch typischerweise 2-5 Minuten: deutlich länger als der Timeout.
Die architektonische Lösung: Der Endpunkt pull_list_sync_async verwendet ein Fire-and-Forget-Muster über die PHP-Funktion fastcgi_finish_request(). Konkret läuft es so ab: Der Server (1) empfängt den Cron-Aufruf, (2) validiert das X-Sync-Token, (3) antwortet mit HTTP 200 in unter 100 ms, (4) schließt die HTTP-Verbindung und (5) führt die eigentliche Synchronisationsarbeit im Hintergrund fort. cron-job.org erhält sein HTTP 200 innerhalb des Timeouts und ist zufrieden, während der Server die eigentliche Synchronisation in seinem eigenen Tempo abschließt.
Dieses Muster ist elegant, hat aber eine Einschränkung: Schlägt die Synchronisation nach dem Fire-and-Forget still fehl (MySQL-Timeout, voller Speicherplatz für Cover usw.), erfährt cron-job.org davon nichts. Zur Absicherung schreibt der Server bei jedem Schritt einen Log-Eintrag in _logs/pull_list_cron.log, wodurch sich fehlgeschlagene Synchronisationen im Nachhinein diagnostizieren lassen.
Der Disk-Cache für Cover: warum und wie
Die von Metron abgerufenen Comic-Cover werden in einem lokalen Disk-Cache des Servers gespeichert (Verzeichnis cache/metron_covers/). Dieser Cache ist entscheidend für die Zuverlässigkeit der Anzeige. Vor der Einführung des Caches (Sprint v5.105, Ende April 2026) wurden die Cover direkt über das Metron-CDN referenziert: was aufgrund der vom CDN auferlegten Hotlinking-Beschränkungen in etwa der Hälfte der Fälle zu defekten Bildern führte.
Mit dem Disk-Cache läuft der Workflow wie folgt ab: (1) Der Sync-Cron-Job löst den Download fehlender Cover über einen PHP-curl-Befehl aus; (2) jedes Cover wird unter dem Namen {slug}.jpg in 300×450 Pixeln gespeichert; (3) ein serverseitiger HTTP-Proxy liefert diese Dateien über die URL /api.php?action=cover_proxy&slug=X aus, wodurch das Metron-CDN vollständig umgangen wird, sobald das Cover im Cache liegt. Ergebnis: eine Anzeigequote der Cover von über 99,5 %.
Performance: Was eine tägliche Synchronisation an Ressourcen kostet
Für technisch Interessierte hier die Größenordnungen einer typischen täglichen Synchronisation im Juni 2026: (1) Metron-Anfragen: 1 REST-Aufruf pro Verlag (~10 Hauptverlage), also 10 HTTP-Anfragen in unter 5 Sekunden; (2) Datenvolumen: 400-600 KB verarbeitetes JSON; (3) MySQL-Anfragen: ~1.200 INSERT-IGNORE-Befehle (einer pro Solicitation, idempotent) in unter 2 Sekunden; (4) Download fehlender Cover: typischerweise 20-50 neue Cover pro Tag, also 1-3 MB heruntergeladen in 30 Sekunden; (5) Gesamtdauer: 2-5 Minuten pro Tag; (6) monatliche Kosten: marginal (vollständig im bestehenden OVH-Shared-Hosting enthalten, keine Mehrkosten).
Diese Sparsamkeit ist Teil der Philosophie von My Comics Collection: Die Grenzkosten der Pull List sind vernachlässigbar, sodass sie ohne Aufpreis im Abonnement enthalten ist. Das Abonnement finanziert die Wartung und Weiterentwicklung.
Häufig gestellte Fragen
Jeden Morgen um 9 Uhr Pariser Zeit. Eine externe geplante Aufgabe ruft dann den Server auf, der die neuen Solicitations abruft, geänderte Termine aktualisiert, fehlende Cover herunterlädt und Abonnenten benachrichtigt, deren Pull List betroffen ist.
Diese Zeit entspricht 3 oder 4 Uhr in New York, wenn die amerikanischen Verlage ihre nächtlichen Aktualisierungen beendet haben: Die Daten sind frisch und für die nächsten 24 Stunden stabil. Die Serverlast ist noch gering, und französischsprachige Nutzer, die die App früh am Tag öffnen, finden einen aktuellen Kalender. Nutzer im asiatisch-pazifischen Raum sehen möglicherweise die Daten des Vortags, ein bewusster Kompromiss.
Das System beruht auf vier Schichten, die die Zuständigkeiten trennen: Datenquelle, täglicher Auslöser, Server und Anzeige. Hat eine einen vorübergehenden Ausfall, laufen die anderen weiter. Der Cache des Servers behält die vorherigen Daten, was leere Seiten vermeidet.
Vor der Einführung des Caches, Ende April 2026, wurden die Cover direkt von der Quelle eingebunden und wurden wegen Ladebeschränkungen jedes zweite Mal nicht angezeigt. Jetzt werden sie in 300 x 450 Pixeln heruntergeladen und über einen lokalen Proxy ausgeliefert. Die Anzeigequote liegt über 99,5 %.
Eine vollständige Synchronisierung dauert typischerweise 2 bis 5 Minuten, da sie mehr als 400 Solicitations verarbeitet und täglich 20 bis 50 neue Cover herunterlädt. Der Server antwortet sofort auf den geplanten Aufruf und arbeitet dann im Hintergrund weiter. Die Kosten sind marginal, sodass die Pull List ohne Aufpreis im Abonnement enthalten sein kann.