Núcleo de pagos. Byte4Bit, 2023 hasta hoy. Ingeniero backend senior. Node.js, TypeScript, AWS.
88Pay
Un núcleo de pagos que lideré desde cero a través de una migración completa a microservicios: pagos, cuentas, identidad, ficheros, analítica, notificaciones y APIs públicas.
El problema
Un núcleo de pagos no es un servicio que creció demasiado. Son siete conversaciones distintas sobre fallos vistiendo un solo despliegue, y la primera decisión de migración es dónde van las costuras.
Lideré el núcleo desde cero: pagos, cuentas, identidad, ficheros, analítica, notificaciones y las APIs públicas, como servicios en Node.js y TypeScript moviendo dinero real con validación estricta, rate limiting, código seguro y observabilidad.
Siete dominios con sus propias fronteras
Cada contexto es dueño de sus datos y de su modo de fallo, así que un incidente en notificaciones no es un incidente en pagos.
Validación antes de que el dinero se mueva
En un sistema de pagos un bug es un problema contable, así que la validación estricta y el rate limiting van en la primera versión y no en una pasada de endurecimiento.
Las APIs públicas como superficie deliberada
El contrato externo se diseña en lugar de filtrarse, que es lo que evita que una refactorización interna se convierta en una rotura de cara al cliente.
Decisiones y el precio que pagué por ellas
Dividir por dominio, no por capa
Las fronteras siguen los siete contextos de negocio, así que un cambio en cómo funcionan las cuentas toca un servicio en lugar de una capa horizontal que los cruza todos.
Trade-off aceptado
Siete desplegables cuestan más atención operativa que uno, y algunos flujos ahora cruzan una frontera de red que antes era una llamada a función.
Tratar cada escritura como un evento contable
La validación estricta, el rate limiting y la revisión de código seguro van delante de cualquier cosa que mueva dinero, porque el coste de una escritura equivocada no es un reintento.
Trade-off aceptado
Más peticiones rechazadas en el borde, y más trabajo para dejar pasar una transacción legítima pero inusual.
Observabilidad como requisito de primera clase
Un sistema de dinero tiene que responder "qué le pasó a esta transacción" como una consulta, no como una investigación.
Trade-off aceptado
La instrumentación se escribe junto a la funcionalidad y se mantiene para siempre, la lea alguien o no.