Pruebas de carga de una API de infracciones sin copiar datos de producción
La carga realista se obtiene reproduciendo formas, proporciones y estados, no copiando patentes o respuestas de clientes a un entorno de prueba.
Por Marco Ferreiro ·
Probar una API con millones de filas copiadas desde producción parece la forma más directa de obtener realismo. También multiplica el riesgo: patentes, identificadores, payloads y relaciones terminan en entornos con más personas, herramientas y copias temporales. La carga que interesa puede modelarse sin trasladar esos registros.
El objetivo es reproducir comportamiento estadístico y contractual, no recrear clientes.
Definir qué se quiere forzar
“Cien solicitudes por segundo” es sólo una parte. Una API de infracciones tiene recorridos distintos: crear una consulta, reintentarla, consultar estado, recibir callbacks, paginar resultados y aplicar límites. Cada escenario consume recursos diferentes.
Antes de generar datos se define mezcla, concurrencia, duración, tasa de llegada y criterio de salida. También se establece un techo que impida afectar servicios compartidos.
Construir identificadores inequívocamente sintéticos
Los datos de prueba usan prefijos y rangos que la aplicación reconoce como no reales. No se eligen patentes con formato válido al azar, porque podrían coincidir con un vehículo. Se crean identificadores internos que nunca salen hacia proveedores y payloads con valores imposibles fuera del sandbox.
La base de prueba incluye relaciones consistentes: una consulta padre, estados permitidos, eventos idempotentes y resultados sintéticos. Así se prueba integridad sin material personal.
Reproducir forma y distribución
El realismo proviene de métricas agregadas: porcentaje de respuestas vacías, resultados con varias actas, tamaño de cada objeto, cantidad de fuentes, demora simulada y frecuencia de errores. Cada celda usada para derivar parámetros debe cumplir el umbral de al menos cien casos y excluir identificadores.
No se copian textos de actas ni combinaciones raras. Se generan descripciones neutras de longitud equivalente y montos ficticios claramente fuera de uso comercial.
Calibrar sin llevarse el historial
La calibración se hace con histogramas agregados y límites, no con filas. Por ejemplo: tamaños de respuesta agrupados, cantidad de fuentes por ejecución y proporción de estados por una ventana definida. Se descartan celdas con menos de cien casos y valores extremos que podrían volver reconocible una consulta singular.
El generador guarda la versión de esos parámetros, no el conjunto que los originó. Si una distribución cambia, se crea una versión nueva y se compara el rendimiento bajo ambas. Esto permite reproducir capacidad histórica sin conservar una copia encubierta de producción.
Doblar proveedores, no sobrecargarlos
Una prueba interna no debe disparar miles de consultas contra portales oficiales. Además del riesgo operativo, eso mezcla el rendimiento propio con límites que no controlamos. Cada proveedor se reemplaza por un simulador que reproduce latencias y respuestas previstas.
Luego puede ejecutarse una prueba separada, pequeña y autorizada de integración. Sus resultados no se presentan como capacidad máxima del proveedor.
Bloquear efectos secundarios
El entorno de carga usa credenciales exclusivas, dominios de correo no entregables y webhooks capturados por receptores de prueba. Los cobros, mensajes, altas de usuarios y alertas externas quedan deshabilitados.
También se prueba aislamiento: una credencial sólo ve su tenant sintético y ninguna respuesta incluye campos internos. OWASP advierte sobre exposición excesiva cuando una API serializa más datos de los necesarios; la carga no debe ocultar ese control de seguridad.
Medir por percentiles y resultado
El promedio puede verse bien aunque una minoría espere demasiado. Se registran p50, p90, p95 y p99, junto con tasa de error, colas, saturación, reintentos y respuestas limitadas. Cada métrica se separa por operación y escenario.
Una respuesta rápida pero incorrecta no cuenta como éxito. Se validan schema, tenant, idempotencia y estado final de una muestra determinista.
La prueba se ejecuta por etapas: calentamiento, carga objetivo, pico breve y recuperación. Después del pico se comprueba que las colas desciendan, que no queden locks y que la latencia vuelva a su base. Medir sólo los segundos de mayor tráfico oculta el costo de recuperación.
Hacer la prueba reproducible
El informe fija versión de código, configuración, generador, semilla, volumen y hora. Con la misma semilla se puede repetir exactamente el conjunto. Con semillas diferentes se comprueba que el sistema no fue optimizado para una sola secuencia.
Los datos sintéticos también requieren control. NIST señala que la síntesis puede conservar riesgo o introducir distorsiones cuando deriva de información sensible. Por eso documentamos cómo se generaron, qué agregados usaron y cuándo se destruye el entorno.
Una buena prueba de carga no necesita saber qué patente consultó una persona. Necesita saber qué forma tiene el trabajo, cuánto llega, cómo se distribuye y qué invariantes deben seguir cumpliéndose cuando aumenta la presión.
Metodología
- Alcance
- Diseño de escenarios de rendimiento para una API multiempresa sin copiar datos de producción.
- Unidad de análisis
- Solicitud sintética y recorrido completo por cola, persistencia y respuesta controlada.
- Cobertura
- Carga, latencia, errores, aislamiento, límites y recuperación; proveedores externos reemplazados por simuladores.
Limitaciones
- Los dobles no reproducen toda la variabilidad de un portal externo.
- Las proporciones agregadas deben superar umbrales de privacidad y no conservar combinaciones singulares.
Fuentes
- NIST Special Publication 800-188: De-Identifying Government Datasets — National Institute of Standards and Technology (consultada el )
- OWASP API Security Top 10 — OWASP Foundation (consultada el )
- Testing for Excessive Data Exposure — OWASP Foundation (consultada el )
Preguntas frecuentes
¿Anonimizar una copia de producción alcanza?
No siempre. Persisten riesgos de reidentificación, campos olvidados y copias fuera de control. Para carga funcional suele ser más seguro generar datos sintéticos desde un contrato.
¿Cómo se logra realismo sin datos reales?
Se modelan tamaños, proporciones, estados, relaciones y patrones temporales agregados, sin reproducir personas ni registros identificables.
¿La prueba puede llamar a portales oficiales?
No como carga masiva. Se usan dobles controlados; cualquier prueba externa necesita autorización, límites estrictos y un objetivo separado.
Notas relacionadas
Cómo diseñar un sandbox de API útil sin usar patentes ni personas reales
Un entorno de prueba sirve cuando reproduce decisiones y fallas del contrato, no cuando copia expedientes de producción. Los escenarios deterministas hacen posible probar sin PII.
Aislamiento entre flotas: las pruebas negativas de una API de multas
Autenticarse como una empresa no alcanza. IDs, cursores, filtros y exportaciones deben resistir intentos cruzados sin revelar que la flota de al lado tiene un acta más de la que debería.
Rate limits de una API de multas: 429, cuotas y reintentos
Un 429 puede señalar una ventana agotada, demasiada concurrencia o protección temporal, mientras una cuota comercial mide otro período. Un contrato explícito evita que el cliente reintente todos los casos igual.