Tecnología
La base de datos relacional principal: consultas complejas, índices, transacciones, JSONB y optimización bajo carga.
PostgreSQL ha sido mi base de datos relacional principal durante nueve años, y la trato como una herramienta completa de ingeniería de datos, no solo como un almacén. Empiezo por el diseño del esquema: normalizo los datos donde corresponde, elijo los tipos de columna correctos, establezco restricciones de integridad (NOT NULL, UNIQUE, CHECK, claves foráneas con reglas de cascada bien pensadas) y defino claves primarias que reflejan el sentido de negocio. Para el dinero y las cantidades precisas nunca uso números de coma flotante: solo numeric/decimal con precisión explícita o enteros en unidades mínimas. Una de las fortalezas de PostgreSQL es su SQL rico: trabajo con soltura con funciones de ventana, CTE y consultas recursivas, agregados, uniones LATERAL y cláusulas FILTER, lo que permite resolver tareas analíticas directamente en la base de datos sin volcar los datos en la aplicación. El rendimiento es una disciplina aparte: leo los planes de consulta con EXPLAIN ANALYZE, elijo los índices adecuados (B-tree, GIN, GiST, parciales y de cobertura), vigilo el hinchazón de las tablas, ajusto autovacuum y analizo las estadísticas del planificador. Comprender los niveles de aislamiento de transacciones, los bloqueos y MVCC me ayuda a evitar deadlocks y anomalías durante la escritura concurrente. Para los datos semiestructurados uso JSONB con índices GIN, para la búsqueda de texto completo el motor integrado con tsvector, y para los geodatos, extensiones. Realizo las migraciones con cuidado: en las tablas grandes tengo en cuenta el riesgo de bloqueos prolongados durante un ALTER, uso estrategias de creación de índices no bloqueantes y planifico ventanas de mantenimiento. Garantizo la fiabilidad mediante una estrategia de copias de seguridad bien pensada, recuperación a un punto en el tiempo (point-in-time recovery), replicación en streaming y réplicas de lectura para distribuir la carga de lectura. Del lado de la aplicación vigilo el pool de conexiones (PgBouncer), combato el problema N+1 a nivel del ORM y almaceno en caché las consultas calientes. La experiencia me ha enseñado que una base de datos bien diseñada es la mitad del éxito de todo el sistema: establece las restricciones de integridad, previene la inconsistencia de los datos y escala junto con el producto, manteniéndose predecible bajo carga real.
Una pasarela de pago de alta carga en Laravel y Go: procesamiento de pagos con idempotencia garantizada y un tiempo de actividad del 99,98%.
Una API única sobre una decena de servicios de mensajería: cálculo de costes, creación de pedidos y seguimiento en tiempo real.
Recopilación y procesamiento de un flujo de eventos con paneles en tiempo real en Go, PostgreSQL y Redis.
Suscripciones, planes y cargos automáticos con un cálculo preciso del dinero y tareas idempotentes.
Un marketplace de dos caras de proveedores y clientes con búsqueda, pedidos y transacciones seguras.
Extracción gradual de microservicios de un monolito sin tiempo de inactividad: límites de dominio, eventos y orquestación en Kubernetes.