Background jobs : Sidekiq, Asynq, ou maison ?
Stack Go, besoin de cron + retries + dead-letter. J'hésite entre Asynq (Redis) et un truc maison avec Postgres skip-locked.
// 13 sujets · APIs, bases de données, infra applicative
Stack Go, besoin de cron + retries + dead-letter. J'hésite entre Asynq (Redis) et un truc maison avec Postgres skip-locked.
Cache-Control, ETag, stale-while-revalidate. Tout est dans le spec depuis 20 ans, personne ne s'en sert. Petit guide condensé.
Mongo c'est sympa pour le proto, douloureux pour le run. JSONB + indices partiels Postgres = 95% des cas Mongo, en relationnel.

On croit découpler avec Kafka mais on couple via le contenu des events. Schémas explicites + contract testing : absolument nécessaire.
Déplacé un microservice de Postgres vers SQLite (mode WAL). Latence p99 : 80 ms → 4 ms. Pas adapté à tous les cas mais largement sous-estimé.
12 ans de bugs cumulés. Voici les 8 règles que j'applique avant chaque ALTER TABLE sur la prod.
On utilisait Redis avec sliding log, RAM qui explose. Passage au token bucket : 10x moins de RAM, comportement identique côté users.
Équipe connaît ni l'un ni l'autre. Service stateless, beaucoup d'I/O réseau. Go pour la productivité, Rust si peur de la GC ?
Workshop interne : 90% des problèmes DB c'est la taille du pool. Petite démo Postgres dans le repo.

Pour les sessions internes, je suis revenu au cookie + session store. Plus simple à invalider, moins de pièges.
Pour moi : tRPC quand front+back en TS, GraphQL si gateway public, REST pour le reste. Vos critères de décision ?
/v1/, /v2/ c'est moche mais explicite. Accept: vnd.api.v2 c'est élégant mais personne ne sait débugger. J'ai choisi l'URL.
Après 3 ans de microservices, on a tout regroupé dans un monolithe modulaire. Latence -70%, coût infra -60%, équipe plus heureuse.