Vermutech #45
Aquesta setmana hem tingut una moguda prou important amb el nostre proveïdor de correus transaccionals (Sendgrid). És el proveïdor que fem servir per enviar tots els correus del sistema de ticketing, i resulta que, sense previ avís, ens va bloquejar el compte.
Havíem activat l’enviament d’emails d’un servei per monitoritzar errors i, durant l’última setmana, enviàvem força correus (tot i estar dins del volum permès), però van considerar que era una activitat sospitosa i van bloquejar tot el compte. Això ens va portar a buscar un nou proveïdor, activar-lo i configurar-lo ràpidament.
Ens hem decidit per Postmark, i la veritat és que m’agrada més que Sendgrid. Té una funcionalitat de servidor en mode staging que és molt útil per fer proves.
Començo amb algunes recomanacions,
💾 Programari
Mailhog: Si el teu proveïdor d'enviament de correus no t'ofereix un servidor de proves, aquest és una alternativa de codi lliure que pots instal·lar fàcilment a la teva infraestructura. Permet capturar i visualitzar els correus de test sense que siguin enviats realment.
🤔 Curiositats
Timelock: Encripta un missatge perquè només es pugui llegir en el futur.
📦 Recursos
Incremental View Maintenance (IVM): refrescar vistes materialitzades de forma ràpida i eficient.
🌟 El concepte
Aquesta setmana vull parlar de les race conditions, un concepte clau quan es treballa amb sistemes concurrents.
Una race condition es produeix quan dos o més processos accedeixen o modifiquen dades compartides al mateix temps i el resultat final depèn de l'ordre d'execució. Això pot provocar errors aleatoris difícils de detectar i reproduir.
Un exemple típic seria dues persones intentant comprar l'última unitat d'un producte alhora. Sense mecanismes de control, el sistema podria vendre el mateix producte dues vegades.
Per evitar les race conditions, existeixen diferents estratègies:
Locks: bloquejar l'accés a les dades mentre un procés les modifica.
Transaccions: assegurar que un conjunt d'operacions es fan de forma atòmica.
Operacions atòmiques: garantir que una acció no es pot interrompre per cap altra.
Idempotència: dissenyar accions que produeixin el mateix resultat encara que s'executin diverses vegades.
Control de versions o timestamps: comprovar que les dades no han canviat abans d'aplicar modificacions.
Quan el problema està dins d'una base de dades que suporta bloquejos i transaccions, com PostgreSQL, és relativament senzill de gestionar. A GISCE-TI, fem servir PostgreSQL també com a motor de bloquejos utilitzant els Advisory Locks, que ens permeten controlar concurrència de manera senzilla i segura entre diferents processos.
💖 Feedback
Si t’ha agradat i em vols ajudar, fes arribar aquest contingut a qui creguis que li pot interessar, i entra al canal de Telegram per comentar la publicació.