← Volver al índice

Informe Backend API: Novapay Spring Boot

Spring Boot 3 Java 21 PostgreSQL Resiliencia & Retry Docker

Resumen Ejecutivo y Arquitectura del Sistema

Este informe documenta el diseño y la implementación del motor backend de Novapay, desarrollado con Spring Boot 3.2 y Java 21. La aplicación fue concebida como un middleware centralizado capaz de recibir transacciones comerciales emitidas por dispositivos TPV cliente (tablets Android, pantallas táctiles e interfaces móviles en Flutter) y procesar de forma transparente la firma digital, el encadenamiento de huellas criptográficas SHA-256 y el envío regulatorio hacia las distintas administraciones tributarias españolas.

La elección de Java 21 permite utilizar hilos virtuales (Project Loom) para atender de forma concurrente cientos de conexiones REST simultáneas provenientes de cajas registradoras sin penalización en memoria, mientras que Spring Framework proporciona abstracción para la persistencia relacional relacional con JPA/Hibernate y el empaquetado de servicios web SOAP mediante Spring WS.

Módulo Cripto Java

100%

Implementado & Testeado

Cálculo SHA-256 & Firma RSA X.509

Transporte Multi-Hacienda

90%

AEAT SOAP + TicketBAI REST

Adapter Pattern Integrado

Infraestructura & Contenedores

Docker

Despliegue Multi-Entorno

Spring Boot + Nginx + Postgres

Estado de Madurez de Componentes

Desglose porcentual del desarrollo de la aplicación backend. Se priorizó el desarrollo del motor criptográfico de encadenamiento por ser el requisito legal más estricto.

Hitos de Desarrollo Cumplidos

Secuencia técnica ejecutada para construir el ciclo de vida completo de la factura electrónica en el servidor:

✓

1. Motor Criptográfico SHA-256

Garantía de encadenamiento inalterable mediante hash concatenado de facturas previas.

✓

2. Capa de Servicios Spring Boot

Controladores REST `@RestController` y servicios de negocio transaccionales `@Service`.

✓

3. Persistencia Relacional PostgreSQL

Inscripción inmediata de registros con estado `PENDING` antes de cualquier transmisión externa.

4

4. Cola Asíncrona de Reintentos

Mecanismo asíncrono `@Scheduled` para la retransmisión autónoma ante caídas de red.

Arquitectura Capa por Capa (Spring Boot)

El backend aplica el principio de responsabilidad única. Cuando una aplicación cliente emite una venta, el paquete JSON ingresa por la capa de controladores REST, se transforma a entidades del dominio, se procesa en el servicio de negocio garantizando la integridad de la base de datos y finalmente se deriva al módulo de transporte correspondiente.

Haga clic en cualquiera de las capas de la izquierda para desplegar el fragmento de código Java real y su especificación técnica.

JAVA
👈

Selecciona una capa a la izquierda para desplegar los detalles de código.

El "Router" Fiscal Regional

España cuenta con un mapa fiscal descentralizado donde coexisten normativas distintas. El motor de Novapay actúa como un enrutador inteligente: inspecciona el NIF y el código postal del contribuyente para seleccionar automáticamente el empaquetado y el protocolo de red correspondiente.

🧾
Factura Venta
Payload JSON Genérico
⚙️
Procesador
Seleccione normativa arriba
🏢
Sede Tributaria
Esperando selección...

Sistema de Resiliencia y Cola Asíncrona

En el punto de venta (TPV) no es admisible bloquear la pantalla de cobro ni hacer esperar al cliente final si los servidores de la Agencia Tributaria están caídos o sufren latencia. Por ello, Novapay aplica un principio de resiliencia estricto: la transacción se guarda primero en la base de datos PostgreSQL local en estado PENDING y se responde un estado OK_LOCAL a la caja registradora en menos de 50 milisegundos.

La retransmisión hacia los servidores de Hacienda la gestiona un hilo asíncrono secundario programado con el algoritmo de **Espera Incremental (Exponential Backoff)**. Esto evita saturar la red con peticiones consecutivas durante una interrupción de servicio.

Estrategia Exponential Backoff

Intervalos de espera exponenciales entre intentos (1s, 2s, 4s, 8s, 16s...) para prevenir tormentas de peticiones.

Reglas de Negocio de Resiliencia

  • 1 Persistencia Asentada Primero: Jamás se realiza una llamada remota sin haber asegurado el registro de la factura en PostgreSQL.
  • 2 Respuesta Inmediata al TPV: La caja registradora imprime el ticket con el código QR y continúa vendiendo sin bloqueo.
  • 3 Confirmación CSV Oficial: Al recibir HTTP 200 OK y el Código Seguro de Verificación (CSV), se actualiza el estado del registro a SENT.
  • 4 Alerta Operativa: Tras 10 intentos fallidos, se genera un log de auditoría pero NO se elimina el registro de la base de datos.

Infraestructura de Contenedores Docker

Toda la solución se encapsula mediante Docker Compose para garantizar portabilidad. Nginx opera como Proxy Inverso perimetral realizando la terminación SSL HTTPS (certificados Let's Encrypt), filtrando peticiones maliciosas (límite estricto de 56KB por cuerpo para evitar desbordamientos de búfer) y reenviando el tráfico limpio a Spring Boot en el puerto local 8080.

Arquitectura del Stack Docker

Nginx Reverse Proxy
SSL HTTPS (Let's Encrypt) • Rate Limit • 56KB Max Payload
Novapay Backend (Java 21)
Spring Boot 3.2 • Hilos Virtuales • Puerto 8080 (Privado)
PostgreSQL 16 DB
Volumen Persistente `pgdata` • Integridad Relacional

Checklist Operaciones y Despliegue

1. Sincronización DDNS y Dominio

Enlace dinámico de la IP pública mediante DuckDNS para permitir conectividad HTTPS desde las tablets TPV.

2. Certificados TLS Let's Encrypt

Generación y renovación automática mediante Certbot. Previene bloqueos SSL en clientes móviles.

3. Aislamiento de Volúmenes de Datos

Persistencia fuera del contenedor mediante - ./pgdata:/var/lib/postgresql/data para respaldos sencillos.

4. Migración sin Interrupción a Cloud

Traspaso directo del archivo docker-compose.yml a AWS/Cloud en menos de 15 minutos.

← Volver a la portada ↑ Volver arriba
🏠