Salud y readiness
GET /health responde liveness. GET /readyz responde una entrada por dependencia.
El resultado del handshake sirve durante 20 segundos, por lo que readiness nunca marca a BACEN por solicitud. El breaker en el nivel de pod se abre solo cuando todos los breakers por institución están abiertos. Una institución con fallos mantiene el pod listo y responde
SCR-1002.
Al apagar, /readyz pasa a 503 primero, y el listener permanece abierto tres segundos. READYZ_DRAIN_DELAY lo anula.
Configuración en tiempo de ejecución
Nueve espacios de nombres llegan a un operador en
/v1/system, bajo el ámbito scr:system:write. La tabla lista los siete que el servicio lee. scr.cors y scr.postgres también existen en el catálogo. El servicio toma su configuración de cross-origin y de pool de conexiones desde las variables de entorno.
Un cambio de nivel de log surte efecto de inmediato. Un cambio de retención surte efecto en el siguiente barrido de purga. El servicio lee cualquier otro espacio de nombres al iniciar, por lo que un cambio ahí surte efecto en el siguiente reinicio. Consulta System plane.
Cada perilla tiene límites finitos. El plazo de solicitud se detiene por debajo de 28 segundos, por lo que una solicitud nunca sobrevive a la gateway. El tope de conexiones acepta 1 o 2.
Credenciales y rotación
El tipo de secret store elige la fuente de la credencial. El tipo de entorno lee el usuario y la contraseña desde el entorno de despliegue. El tipo de vault gestionado los resuelve por institución, y la base de datos guarda solo una referencia. El tipo de vault gestionado también habilita
PUT /v1/scr/credential. Escribe primero el vault y luego los metadatos, por lo que un reintento reutiliza la referencia.
La contraseña nunca llega a un log, un span, o un error. La operación de estado devuelve un nombre de usuario enmascarado. Una caída del vault responde SCR-1002 y nunca activa el breaker del canal.
Caché y retención
La caché de resultados contiene una entrada por institución, índice ciego del prestatario, y mes de referencia. Cada valor lleva el sobre en reposo de la fila de auditoría. Una entrada del mes en curso vive cuatro horas, una entrada de un mes cerrado 720 horas. Una entrada ilegible cuenta como un fallo de caché, y un despliegue sin Redis siempre falla. La purga de auditoría permanece desactivada hasta que un operador establece una ventana. Una ventana vacía no elimina nada. Con una ventana, un barrido diario elimina las filas más antiguas en lotes acotados, y nunca las archiva.
Métricas y trazas
La exportación por defecto es OTLP push. Un listener de scrape de Prometheus es de activación explícita, en una dirección loopback,
127.0.0.1:9075 por defecto. El puerto de la aplicación no tiene ninguna ruta /metrics.
Dos histogramas miden una consulta: de extremo a extremo, y la sobrecarga sin la llamada a BACEN. Sus etiquetas llevan la institución, la marca de acierto de caché, y el resultado, nunca al prestatario. Los contadores cubren códigos de decodificación desconocidos y filas purgadas.
Postura de despliegue
Un nombre de entorno de producción o el modo de despliegue SaaS selecciona la postura estricta. El arranque estricto exige un modo de despliegue explícito, el host, la base de datos y el usuario de Postgres, y autorización sobre una dirección https. Exige la URL base del canal sobre https, y TLS en Postgres y en cualquier Redis o broker configurado. Exige dos claves en reposo distintas y una región para el vault gestionado, y prohíbe un rango de proxy comodín. Una lista de brokers o un host de Redis en blanco rechaza el arranque, a menos que un operador declare la exclusión explícita. El log de arranque y
/readyz entonces nombran las protecciones degradadas.
Multi-tenancy necesita la URL del directorio de tenants y una clave de servicio. De lo contrario, un despliegue sirve a una institución.
Un operador aplica el esquema fuera del proceso en tiempo de ejecución. El servicio lo lee y nunca lo crea.