Saltar al contenido principal
Una consulta se ejecuta en una sola solicitud. Lerian SCR sirve lo que la caché ya contiene y llama a BACEN por el resto. Luego decodifica la respuesta y audita el resultado antes de responder.

Solicitud de consulta


Un consumidor publica una consulta con el documento del prestatario, el tipo de cliente, y un rango de fechas de referencia. La solicitud también declara la autorización del titular conforme a la LC 105/2001. Esa declaración es una marca obligatoria, y el registro de consentimiento permanece con la institución. La llamada es síncrona. El resultado decodificado llega en el cuerpo de la respuesta de la misma solicitud, y no existe un flujo de crear y luego sondear. La respuesta lleva un identificador para una relectura posterior. BACEN cobra por cliente y por fecha de referencia, por lo que un rango acotado cuesta menos. Cada solicitud lleva una clave de idempotencia, y un reintento que repite un resultado almacenado no paga una segunda tarifa.

Resolución de credenciales y protecciones del canal


Lerian SCR resuelve la credencial de canal de la institución antes de abrir la ruta del circuit breaker. Un fallo de credencial es un fallo local, y una caída del vault nunca activa el breaker del canal. El adaptador entonces emite un GET HTTPS a la operación /wsscr2n/cliente/resumo de BACEN y establece HTTP Basic en la solicitud. El canal autentica solo al servidor, a través del almacén de certificados del sistema anfitrión, con TLS 1.2 como mínimo y sin certificado de cliente. Tres protecciones se ubican delante de la llamada, en este orden. La coalescencia single-flight fusiona consultas concurrentes idénticas en una sola llamada upstream. Un circuit breaker decide entonces si la llamada continúa. Dentro del breaker, un semáforo limita las conexiones concurrentes a dos. Por defecto, el breaker se activa tras cinco fallos consecutivos, o tras una tasa de fallos de 0,5 en al menos diez solicitudes. Luego se enfría durante 30 segundos. Un fallo de transporte, un error de la plataforma de BACEN o una respuesta que el servicio no puede leer activa el breaker. Una respuesta de “sin posición” y un rechazo del lado del cliente no lo hacen. Un breaker abierto devuelve SCR-1002 de inmediato y no llama a BACEN.

Caché de resultados y tarifa


Lerian SCR lee una caché de Redis antes de llamar a BACEN. La caché contiene una entrada por prestatario y mes de referencia. La clave lleva al prestatario solo como un índice ciego. Cada valor lleva el mismo sobre AES-256-GCM en reposo que la fila de auditoría. Un acierto completo omite la llamada a BACEN y la tarifa, y aun así audita y emite. Un acierto parcial obtiene un rango que cubre todos los meses faltantes, así que un mes en caché dentro de ese rango se obtiene y se cobra de nuevo. Una solicitud que pide datos frescos omite la lectura y paga la tarifa. Por defecto, una entrada del mes en curso vive cuatro horas, y una entrada de un mes cerrado vive 720 horas. Un mes que BACEN omite se convierte en un marcador de ausencia de posición, por lo que una repetición del mismo rango no vuelve a pagar por ese mes. Cuando BACEN responde después de que la solicitud ya respondió SCR-1004, el servicio aun así escribe esa respuesta en la caché. Una entrada ilegible cuenta como un fallo de caché. Una escritura de caché es best-effort y nunca hace fallar una consulta. Un despliegue sin Redis rechaza las consultas con SCR-9002.

Decodificación


BACEN responde con códigos para modalidad, fuente de fondeo, indexador, variación cambiaria, segmento del acreedor, tipo de garantía, y tipo de información adicional. Lerian SCR resuelve cada código contra las tablas anexas de SCR, que vienen incluidas en el servicio, y devuelve un par { code, description }. Un código desconocido conserva el código, devuelve una descripción nula, e incrementa una métrica de código desconocido. Nunca hace fallar la consulta. Un código vacío devuelve un código vacío sin descripción y no dispara ninguna métrica. El decodificador lee solo códigos de dominio. Nunca ve el documento del prestatario.

Auditoría y eventos


Todo resultado terminal escribe una fila de auditoría. La fila y su evento de outbox hacen commit en una sola transacción, por lo que ninguna consulta queda sin su registro. Una escritura fallida hace fallar la consulta. Responde SCR-9001, un 503 reintentable, cuando la solicitud nunca llegó a BACEN, y SCR-1004, un 502, cuando sí llegó. El consumidor nunca recibe una posición de crédito sin auditar. La fila mantiene sus datos personales bajo cifrado AES-256-GCM y un índice ciego HMAC-SHA256, con dos claves independientes. El outbox lleva dos tipos de evento: studio.lerian.br-scr.consulta.completed para una consulta atendida, y studio.lerian.br-scr.consulta.failed para una fallida. El despachador publica ambos en el topic lerian.streaming.br-scr, con lerian.streaming.br-scr.dlq para mensajes envenenados. Un operador puede desactivar la emisión. Las filas entonces permanecen pendientes en el outbox y se envían después de que la emisión vuelve a activarse y el servicio se reinicia.