Vermutech #73
Setmana accidentada, amb un mini constipat que m’ha trencat el ritme. Per sort, dos dies fent una mica més de bondat i ja tornant a la normalitat 💪. La setmana que ve me’n vaig a l’Enlit Europe’25. Com vaig dir per LinkedIn, si algú és per allà, que m’avisi i podem parlar del sector i de tecnologia. A més, presentarem el nostre producte de GIS, així que he estat preparant la presentació per fer allà. A la següent newsletter ja t’explicaré què tal ha anat.
A nivell tècnic, aquesta setmana he treballat en una millora de seguretat de camps relacionats a la base de dades, en acabar de polir el sistema per accedir mitjançant certificat SSL i la gestió d’aquests des del nostre sistema (tenim aquesta eina que hem alliberat que es diu Certbox). També continuo treballant en la millora de la vista Kanban.
Començo amb algunes recomanacions,
💾 Programari
Espanso: Un text expander que funciona amb Linux, Mac i Windows, i que és súper hackejable. Pots fins i tot integrar-hi “custom scripts”. Una passada.
🤔 Curiositats
JuryNow: És una web on pots obtenir un veredicte de qualsevol pregunta que facis o actuar tu com a jurat. No sé fins a quin punt és real i hi ha gent al darrere... o són bots.
📦 Recursos
Què és l’HDR? Quan tirem una foto i s’activa el mode HDR, què és ben bé? Com funciona? Doncs en aquest article està molt ben explicat.
📊 Enquesta
La setmana passada us vaig preguntar com monitoritzeu els vostres serveis, i el resultat va ser claríssim:
La majoria feu servir Prometheus + Grafana, mentre que un terç encara confia en scripts casolans i alertes. Cap vot per solucions comercials ni per Uptime Kuma… i ningú va admetre que no monitoritza res 😅
Aquesta setmana canviem de registre i anem a un tema més personal: els nostres hàbits digitals.
🌟 El concepte
Quan una aplicació comença a créixer de debò, arriba un moment que la base de dades no pot seguir el ritme. Ja no és qüestió de posar-hi més CPU o memòria: cal repartir millor la càrrega. I una de les tècniques més utilitzades per fer-ho és el sharding.
Vol dir dividir una base de dades en trossos més petits (shards), cadascun amb una part de la informació, sovint distribuïts entre diferents servidors. És com si, en comptes de tenir una enciclopèdia sencera en un sol llibre, la repartissis per volums i els posessis en prestatgeries separades. El sistema sap on anar a buscar cada entrada, i això et permet escalar horitzontalment: afegeixes més màquines, no una de més gran.
Hi ha diferents maneres de decidir com es reparteixen les dades:
Per ubicació: si tens persones usuàries repartides per zones geogràfiques, pots separar les dades per país, regió o continent.
Per hash: agafes una clau com l’ID de l’usuari i calcules un hash que et diu a quin shard va.
Per interval: divides les dades en rangs, com ara per dates o blocs d’identificadors.
Per funcionalitat: cada shard conté un domini diferent (per exemple: facturació, autenticació, etc.). Això ja s’apropa més al concepte de microserveis.
Un cop tens la lògica de partició clara, toca veure com s’implementa. I aquí és on entra PostgreSQL, que és la base de dades que més m’agrada.
🔧 Amb PostgreSQL, una de les opcions més potents és fer servir Citus, una extensió que converteix un PostgreSQL clàssic en un sistema distribuït. Permet fer sharding automàtic de taules i manté el suport per SQL estàndard, amb consultes que poden anar a múltiples shards de forma transparent. És com escalar sense haver de renunciar al model relacional.
També es pot fer sharding manual amb taules particionades i alguna capa d’abstracció (triggers, funcions de routing, etc.), però Citus ho fa molt més net.
Com sempre, abans de decidir si cal fer sharding, val la pena revisar si realment és el coll d’ampolla. Però quan toca, és millor tenir-ho previst que haver de reescriure mitja arquitectura a corre-cuita.
💖 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ó.