Microservicios de identidad de terceros
Resuelve quién es un tercero a partir de su número de documento, cruzando la base propia, el servicio de la autoridad tributaria y fuentes públicas.
4
fuentes consultadas en cascada
3
microservicios independientes
0
secretos en el repositorio
Para emitir una factura hay que saber exactamente a nombre de quién se emite, y el dato llega mal: nombres abreviados, apellidos en desorden, razones sociales con puntuación distinta cada vez. Consultar la fuente oficial en cada operación es lento y frágil. Peor aún: cuando un dato cambia, hay que distinguir si el tercero realmente se llama distinto ahora o si solo lo escribieron de otra forma, porque actualizar por cada variación tipográfica genera ruido interminable.
Un conjunto de microservicios que consulta en cascada: primero la base propia, después las transacciones ya existentes, luego el servicio de la autoridad tributaria y por último las fuentes públicas. Cada capa responde más rápido que la siguiente y solo se baja un escalón si hace falta. Un servicio aparte consume una cola de mensajes para actualizar en segundo plano sin bloquear a nadie.
La comparación de nombres no se hace por igualdad de texto, porque “Rodríguez Martínez Luis F.” y “LUIS FELIPE RODRIGUEZ MARTINEZ” son la misma persona escrita de dos maneras. Un servicio en Python convierte ambos nombres a vectores semánticos y mide su similitud: por encima del umbral es la misma identidad escrita distinto y no se toca nada, por debajo es un cambio real que sí debe registrarse. Eso eliminó de raíz las actualizaciones falsas. La descomposición de un nombre en sus partes tampoco es un algoritmo único: nombres de una, dos, tres o más palabras se resuelven con estrategias distintas ensambladas explícitamente al arrancar.
Identificación resuelta en milisegundos en el caso común, sin golpear la fuente oficial, y con las actualizaciones por variación de escritura eliminadas. Cada servicio va en su contenedor y los secretos viven en el almacén de claves, nunca en el repositorio.
Cómo se ve por dentro
Ejemplos ilustrativos de los patrones aplicados, con la razón de cada decisión.
Un cambio real no es lo mismo que otra forma de escribirlo
UMBRAL_MISMA_IDENTIDAD = 0.92
def es_cambio_real(nombre_actual: str, nombre_nuevo: str) -> bool:
"""True solo si el nombre cambió de verdad, no si lo escribieron distinto."""
vectores = modelo.encode([normalizar(nombre_actual), normalizar(nombre_nuevo)])
similitud = float(util.cos_sim(vectores[0], vectores[1]))
return similitud < UMBRAL_MISMA_IDENTIDADLos dos nombres se convierten en vectores semánticos y se compara su ángulo. Por encima del umbral se considera la misma identidad, así que no se genera una actualización que solo sería ruido.
Ejemplo ilustrativo del patrón aplicado; no es código de ningún producto.La clave de API se valida antes de tocar el endpoint
public sealed class ApiKeyEndpointFilter : IEndpointFilter
{
public async ValueTask<object?> InvokeAsync(
EndpointFilterInvocationContext contexto, EndpointFilterDelegate siguiente)
{
var recibida = contexto.HttpContext.Request.Headers["X-Api-Key"];
if (!_validador.EsValida(recibida))
return Results.Problem(statusCode: StatusCodes.Status401Unauthorized);
return await siguiente(contexto);
}
}Un filtro de endpoint corta la petición sin credencial válida antes de que llegue al manejador. La autorización no se repite en cada endpoint ni depende de que nadie la olvide.
Ejemplo ilustrativo del patrón aplicado; no es código de ningún producto.Stack del proyecto
¿Necesitas algo parecido?
Cuéntame tu caso y te digo con franqueza si es viable y cuánto toma.
Hablemos