Les conditions de course en mode WAL (Write-Ahead Logging) de SQLite ont été l'un des bugs les plus difficiles à diagnostiquer dans 0fee.dev. Quand plusieurs workers Celery et le serveur FastAPI accédaient simultanément à la base de données, des écritures étaient perdues, des transactions restaient bloquées en « pending » et des webhooks n'étaient pas enregistrés.
Le problème
Le mode WAL de SQLite permet plusieurs lecteurs simultanés mais un seul écrivain. Quand plusieurs processus (FastAPI + Celery workers) tentent d'écrire simultanément, le verrou d'écriture cause des timeouts et des pertes de données silencieuses.
Les symptômes
- Transactions qui restent en « pending » indéfiniment.
- Webhooks marqués comme livrés dans les logs mais absents de la base de données.
- Doubles écritures sporadiques.
La leçon
SQLite est excellent pour le prototypage rapide et les applications mono-processus. Pour une plateforme de paiement avec plusieurs workers concurrent, PostgreSQL est le bon choix. Cette leçon a motivé la migration de la Session 081.
Cet article fait partie de la série « Comment nous avons construit 0fee.dev ». 0fee.dev est un orchestrateur de paiement couvrant 53+ fournisseurs dans 200+ pays, construit par Juste Thales Gnimavo et Claude depuis Abidjan sans aucun ingénieur humain. Suivez la série pour l'histoire complète de la construction.