4 malsons d'infraestructura que vaig solucionar en la meva plataforma de ticketing

Descobreix com vaig resoldre 4 problemes crítics d'infraestructura en crear una plataforma de ticketing amb Next.js, NestJS i Paystack. Aprèn dels meus errors.

miércoles, 29 de julio de 2026 • 4 min de lectura • Equip Q2BSTUDIO

Lecciones reales sobre pagos, webhooks y caching

Desenvolupar una plataforma de ticketing semblava senzill sobre el paper: els usuaris creen esdeveniments, compren entrades i les validen mitjançant codis QR. No obstant això, en integrar pagaments reals, webhooks de tercers i treballs en segon pla, la complexitat es va disparar. Vull compartir quatre problemes d'infraestructura que vaig resoldre durant el desenvolupament, amb l'esperança que estalviïs setmanes de debugging. Aquests aprenentatges em van portar a replantejar l'arquitectura i a valorar serveis com els que ofereix Q2BSTUDIO en cloud AWS/Azure, on la gestió d'infraestructures crítiques es converteix en un pilar del negoci.

1. El frontend mai no ha de ser la font de veritat per als pagaments

Quan un usuari compra una entrada, és redirigit a la passarel·la de pagament. En tornar, la temptació és confirmar la compra des de la pàgina d'èxit. Greu error: qualsevol pot falsificar aquesta URL. Vaig implementar un patró de confirmació en dues fases: el backend crea una transacció en estat PENDING i retorna un enllaç de pagament. La passarel·la envia un webhook server-to-server amb els detalls. El backend verifica la signatura HMAC, actualitza l'estat a SUCCESS i genera l'entrada. El frontend només mostra el que el backend li diu. Aquesta lliçó de ciberseguretat és fonamental; en solucions de ciberseguretat com les de Q2BSTUDIO s'insisteix a no confiar mai en dades no verificades del costat client.

2. Signatures de webhook: el problema del cos en brut

Per verificar que un webhook prové realment de la passarel·la, cal calcular el hash del payload amb la clau secreta i comparar-lo amb la capçalera de signatura. Els meus hashes fallaven un cop rere l'altre. La causa: el framework parsejava automàticament el JSON, i JSON.stringify() alterava l'ordre exacte dels bytes. La solució va ser habilitar rawBody: true a la configuració del servidor, accedint al buffer sense processar. Utilitzar un tipus personalitzat per a req.rawBody (un Buffer) va permetre calcular el hash correctament. Aquest detall, aparentment menor, esdevé crític quan gestiones pagaments. Si la teva plataforma escala, comptar amb un equip especialitzat en aplicacions a mida com el de Q2BSTUDIO t'estalvia aquests mals de cap.

3. Caché amb Redis: el silenci de les noves versions

Vaig voler cachejar els llistats d'esdeveniments a Redis. Vaig instal·lar les dependències, vaig configurar l'emmagatzematge… i res. Sense errors, sense crashes, però Redis seguia buit. Resulta que la nova versió del mòdul de caché va canviar radicalment: va passar d'un únic magatzem a un array de magatzems amb adaptadors Keyv. La configuració antiga s'ignorava silenciosament i l'aplicació usava memòria local per defecte. Vaig migrar a @keyv/redis, el vaig passar dins d'un array stores: [] i vaig usar la cadena de connexió rediss:// (amb TLS) perquè el Redis d'Upstash ho exigeix. De sobte, la caché va funcionar. Aquest tipus de problemàtiques d'integració són habituals quan es treballa amb serveis cloud; per això triar un partner com Q2BSTUDIO, que domina AWS/Azure, assegura que les transicions de versió no trenquin el teu sistema.

4. Degradació gradual: millor que caure completament

Vaig implementar rate limiting amb Redis. Però, què passa si el servidor Redis té un parpelleig? Per defecte, el client de Redis reintenta 20 vegades i després llança un error. Com que el limitador es troba a cada ruta, una fallada de Redis provocava que tota l'API retornés errors 500. Vaig escriure un envoltori personalitzat sobre la interfície d'emmagatzematge del limitador: si detecta un error de connexió, registra un avís i permet que la petició passi. Prefereixo uns segons de trànsit sense limitar a tenir l'API caiguda per a tothom. Aquesta filosofia de degradació gradual és clau en sistemes resilients, i s'alinea amb les bones pràctiques que apliquen a Q2BSTUDIO quan desenvolupen agents IA o solucions de BI/Power BI que han de continuar funcionant tot i que un component falli.

En conclusió, els tutorials rarament ensenyen a gestionar cadenes de connexió TLS, buffers de webhook o fallades silencioses de caché. Construir aquesta plataforma em va obligar a deixar de pensar com un simple usuari de frameworks i començar a pensar com un enginyer de sistemes. Si estàs desenvolupant el teu propi producte o necessites escalar un d'existent, no subestimis la importància d'una infraestructura ben dissenyada. Empreses com Q2BSTUDIO ofereixen serveis de desenvolupament de programari a mida que integren aquests principis des del primer dia, garantint robustesa, seguretat i rendiment.

UNA PAUSA?

Juga una estona abans de marxar

ELS NOSTRES SERVEIS

Com et podem ajudar

Tens un projecte en ment?

Explica'ns la teva visió i la convertim en una solució de programari. Sigui quin sigui l'abast, fem realitat la teva idea.