Comprobaciones de fraude IP: de 300 ms contra una API externa a 0,04 ms en local

Un equipo ha sacado las comprobaciones de fraude por IP de las APIs externas y las ha llevado a un conjunto de datos local servido desde Redis. La latencia por consulta ha pasado de 300-400 ms a entre 0,04 y 0,1 ms. El problema no era la lógica del filtro: era el viaje de ida y vuelta a un tercero, que además bailaba según la carga que tuviera ese proveedor ese día.

El motivo para moverlo fue un presupuesto de tiempo. Varios endpoints tenían que quedarse por debajo de 50 ms en total y la llamada de fraude se comía ese margen ella sola. La solución no tiene nada de exótica: meter los ASN problemáticos, los rangos de datacenter y las salidas de Tor en un Redis que ya tenían levantado, poner FastAPI delante para resolver las consultas y dejar el lado del proxy en Go, que ya era su stack. El coste de añadir piezas nuevas fue cero.

No dicen con qué frecuencia refrescan esas listas ni de dónde las sacan, que es la parte aburrida del asunto y la que decide si el invento sigue funcionando dentro de seis meses. Tampoco publican el código ni un repositorio donde mirarlo.

Un filtro de primera pasada, no un sustituto

Quien lo cuenta es explícito: esto no es una API de scoring con modelos de machine learning detrás. Es un filtro barato que descarta lo evidente antes de que la petición siga avanzando. Para eso, un milisegundo escaso de latencia es más que suficiente.

El proveedor externo no ha desaparecido del todo. Mantienen uno como respaldo para lo que el conjunto local no cubre, con una diferencia importante: ahora la llamada va en asíncrono en lugar de bloquear la petición. Si el proveedor tarda o se cae, el camino crítico no se entera.

La pregunta que lanza al final es si a otros les pasa lo mismo con la latencia de terceros. En cualquier arquitectura donde una dependencia externa esté en el camino síncrono de cada request, la respuesta es que sí, y que el problema se detecta tarde porque el promedio engaña. La media de 300 ms se ve razonable hasta que la cola de la distribución se estira a un segundo en hora punta y revienta los SLO de los endpoints que sí importan.

Lo que queda por ver es el mantenimiento. Un Redis con listas de rangos y salidas de Tor es rápido y baratísimo de operar, pero envejece: los rangos cambian, aparecen nodos nuevos y el filtro se queda ciego sin que nadie se entere, porque no falla, simplemente deja pasar cosas. Cargar esas listas y tener un proceso que las actualice es la mitad del trabajo, y es la mitad que este equipo no ha contado.