How My Comics Collection's Pull List Updates Every Day: Architecture Explained

The release calendar is built on a 4-layer technical architecture. Layer 1: Metron.cloud, the original data source — a collaborative community database founded in 2018 that aggregates official publisher solicitations under a CC-BY-SA 4.0 license. Layer 2: an external cron job hosted on cron-job.org (free service, 30s timeout) that calls a dedicated My Comics Collection API endpoint every morning at 9:00 AM Paris time. Layer 3: the server API, which fetches fresh data from Metron via their REST API, updates the MySQL upcoming_releases table, and triggers async downloads of any missing covers. Layer 4: the app frontend, which queries that table on every user visit to display an up-to-date calendar.

System architecture: Metron → API → cache → user

This 4-layer design cleanly separates responsibilities: Metron owns the source data (which we consume legally under their license), the cron controls the cadence (we decide when we sync), the server handles persistence (MySQL + disk cache), and the frontend handles display. If any one layer has a temporary outage, the others keep running — the MySQL cache retains previous data even if Metron goes down, preventing blank pages.

The daily cron job: why 9 AM Paris time

The 9:00 AM Paris time slot (UTC+1 or UTC+2 in summer) was chosen to satisfy several operational constraints. (1) US time zone offset: 9 AM Paris is 3–4 AM New York time, when American publishers have finished their overnight updates to the Metron database. At that hour, Metron data is fresh and stable for the next 24 hours. (2) Low server load: 9 AM Paris is still off-peak for most My Comics Collection users, so the cron job doesn't compete with peak user traffic. (3) Ready for the day: French-speaking users who open the app first thing in the morning (8–11 AM) see a freshly updated calendar, which maximizes perceived quality.

One exception: users in Asia/Pacific who visit at midnight Paris time (morning for them) may see yesterday's data before the 9 AM sync runs. That's a deliberate trade-off — we optimize for the EU francophone majority rather than the APAC minority.

The 30s timeout and the async fire-and-forget architecture

One technical constraint of the free cron-job.org service is its 30-second HTTP timeout. If the My Comics Collection server takes longer than 30s to respond, cron-job.org treats it as a failure and sends an error notification. But a full Metron sync — fetching 400+ solicitations, updating MySQL, downloading new covers — typically takes 2–5 minutes, far beyond the timeout.

The architectural solution: the pull_list_sync_async endpoint uses a fire-and-forget pattern via PHP's fastcgi_finish_request() function. In practice, the server (1) receives the cron call, (2) validates the X-Sync-Token, (3) returns HTTP 200 in under 100 ms, (4) closes the HTTP connection, and (5) continues the sync work in the background. cron-job.org gets its HTTP 200 within the timeout and is happy, while the server finishes the real sync at its own pace.

This pattern is elegant but comes with one caveat: if the sync silently fails after the fire-and-forget (MySQL timeout, disk full for cover storage, etc.), cron-job.org will never know. To mitigate this, the server writes a log entry to _logs/pull_list_cron.log at each step, enabling post-mortem diagnosis if a sync failed.

The cover disk cache: why and how

Comic covers fetched from Metron are stored in a local server disk cache (directory cache/metron_covers/). This cache is critical for reliable image display. Before it was implemented (sprint v5.105, late April 2026), covers were served directly from the Metron CDN — which resulted in broken images roughly half the time due to hotlinking restrictions enforced by that CDN.

With the disk cache, the workflow is: (1) the sync cron triggers downloads of missing covers via a PHP curl call; (2) each cover is stored as {slug}.jpg at 300×450 pixels; (3) a server-side HTTP proxy serves these files via the URL /api.php?action=cover_proxy&slug=X, completely bypassing the Metron CDN once a cover is cached. Result: cover display rate above 99.5%.

Performance: what does a daily sync actually cost in resources?

For the technically curious, here are the ballpark figures for a typical daily sync as of June 2026: (1) Metron requests: 1 REST call per publisher (~10 major publishers), totaling 10 HTTP requests in under 5 seconds; (2) data volume: 400–600 KB of JSON processed; (3) MySQL queries: ~1,200 INSERT IGNORE statements (one per solicitation, idempotent) in under 2 seconds; (4) missing cover downloads: typically 20–50 new covers per day, meaning 1–3 MB downloaded in 30 seconds; (5) total wall time: 2–5 minutes per day; (6) monthly cost: marginal (well within the existing shared OVH hosting, no added expense).

This frugality is core to the My Comics Collection philosophy: the Pull List feature is available to free users without undermining the app's overall economics, because its marginal cost is negligible. Premium covers maintenance and new features, not free browsing.