SLOC_Sync.markdown

Draft

Ich schreibe mal runter, wie ich mir den Prozess vorstelle, ohne mir die SLOC API Docs anzuschauen:

• wir starten den SyncSlocSensorsJob
• der nimmt sich alle Sensoren die in den letzten X Stunden nicht gesynct wurden last_synced_at
• bei den am längsten nicht gesyncten anfangend, ruft er die SLOC API in Batches of 10 ab
• bei erfolgreicher Response
  • wird last_synced_at in den 10 Sensoren updated nachdem
  • die Werte in der DB gespeichert wurden
• wenn ein einzelner Sensor (oder dann eine Batch of 10?) fehlschlägt, wird das
  • abgefangen
  • an Sentry gemeldet
  • und der Prozess dann mit der nächsten Batch fortgesetzt
• wenn es mit einem RateLimitError fehlschlägt
  • lesen wir den Timestamp aus
  • brechen den aktuellen Sync ab
  • schedulen einen Nachfolge-Job mit perform_at(timestamp_aus_fehlermeldung + 1s)
• wenn alle durchlaufen, werden die nächst "älteren" Sensoren (also seit X-1 Stunden nicht gesynct) gebatched

Anmerkungen Rate Limit Optimierung

Idealerweise würden wir die SLOC Sensoren aufteilen nach:

• Füllstand
• GPS Position
• Battery Level
• Signal Quality
• ...?

Und die Abfragen in unterschiedlich langen Intervallen vornehmen, um unser Rate Limit noch weiter zu entzerren.

Anmerkung perform_in(timestamp_aus_fehlermeldung + 1s)

Wenn der Job sich selbst scheduled, nutzen wir die Zeit ideal aus und produzieren die niedrigstmögliche Anzahl an Errors.

Allerdings müssen wir sicherstellen, dass er regelmässig läuft - und auch neu startet, wenn zB Redis mal abschmieren oder geleert werden sollte (was extrem selten vorkommt).

Für den Fall sollten wir also noch einen CronJob haben, der den SyncSlocSensorsJob startet, falls noch keiner gescheduled ist.