Cómo diseñar una arquitectura de datos que soporte APIs externas sin que se rompa bajo presión
Cómo diseñar una arquitectura de datos que soporte APIs externas sin que se rompa bajo presión
Muchos equipos técnicos diseñan su arquitectura de datos pensando en sus propias fuentes internas: bases de datos transaccionales, logs de producto, eventos de usuario. Eso funciona bien hasta que el negocio pide integrar señales externas del universo público de Internet: menciones de marca, tendencias sectoriales, cobertura de medios, conversaciones en foros especializados.
En ese momento aparece la fricción. La arquitectura interna está optimizada para datos estructurados y predecibles. Las APIs externas traen volúmenes variables, formatos heterogéneos y latencias que no controlas. Si no se diseña el puente correcto desde el principio, el resultado es una integración frágil que se rompe bajo carga real y genera deuda técnica difícil de pagar.
Este post no va de conceptos. Va de decisiones concretas que los equipos de datos deben tomar antes de conectar su primer endpoint externo.
El error más común: tratar la API externa como si fuera tu base de datos
La primera trampa es asumir que una API de señales externas se comporta igual que una query a tu warehouse interno. No lo hace.
Una API que devuelve menciones del universo público trabaja con ventanas temporales, cuotas por crédito, paginación dinámica y, en ocasiones, resultados que varían ligeramente entre llamadas repetidas por la naturaleza del procesamiento continuo. Si construyes tu pipeline con la misma rigidez que usarías para un SELECT en PostgreSQL, vas a tener problemas.
Qué hacer en cambio:
- Trata cada llamada a la API externa como una fuente eventual, no como una fuente síncrona de verdad absoluta.
- Implementa un buffer de ingesta desacoplado: Kafka, RabbitMQ o cualquier sistema de colas que absorba los resultados sin bloquear el proceso principal.
- Define explícitamente la frecuencia de polling y el TTL de los datos antes de escribir una sola línea de código. ¿Necesitas señales en ventanas de 15 minutos, de 1 hora, de 24 horas? La respuesta cambia completamente el diseño.
Capas de la arquitectura: dónde vive cada responsabilidad
Una arquitectura robusta para señales externas tiene al menos cuatro capas diferenciadas. Mezclarlas es la fuente número uno de deuda técnica.
1. Ingesta y normalización Aquí entra el dato crudo desde la API. La responsabilidad de esta capa es única: recibir, validar el esquema mínimo y enrutar. No transformes, no enriquezcas, no tomes decisiones de negocio aquí. Cualquier error de red o cambio en el contrato de la API se gestiona en este punto sin contaminar el resto.
2. Almacenamiento intermedio (staging) Los datos normalizados llegan a una zona de staging —puede ser un bucket S3, una tabla particionada en BigQuery, o un topic específico en tu sistema de mensajería. Esta capa actúa como "memoria de corto plazo" y permite reprocesar sin llamar de nuevo a la API externa. Es crítica para controlar costes en modelos pay-as-you-go.
3. Transformación y enriquecimiento Aquí sí puedes aplicar lógica: agregaciones, clasificaciones, cruce con datos internos, cálculo de métricas derivadas. Si usas dbt, Spark o un proceso batch, que sea en esta capa, nunca en la de ingesta.
4. Servicio y consumo APIs internas, dashboards, modelos de ML, alertas. Esta capa consume datos ya procesados, nunca crudos. Los equipos de negocio o los modelos de IA no deberían ver el dato sin pasar por las capas anteriores.
Gestión de créditos y costes: el problema que nadie documenta hasta que llega la factura
Las APIs de señales externas suelen operar bajo modelos de consumo variable —créditos por llamada, por volumen de resultados, por frecuencia. Ignorar esto en el diseño arquitectónico es un error clásico.
Algunas decisiones concretas para evitarlo:
- Implementa un rate limiter propio, independientemente del que imponga el proveedor. Controla tú el ritmo de consumo según tus prioridades de negocio.
- Registra el gasto por pipeline y por caso de uso desde el primer día. Si tienes cinco equipos usando la misma API con distintas queries, necesitas saber qué unidad de negocio consume qué.
- Diseña para la reutilización del dato: si dos procesos distintos necesitan las mismas señales en la misma ventana temporal, que compartan el resultado cacheado en staging, no que hagan dos llamadas independientes a la API.
Plataformas como FeedScale exponen APIs REST bajo modelos pay-as-you-go precisamente porque el consumo real varía mucho entre casos de uso. Una arquitectura bien diseñada puede reducir el gasto en API externas entre un 30% y un 60% solo eliminando llamadas redundantes.
Resiliencia: qué pasa cuando la API externa falla
Tu arquitectura debe asumir que la API externa va a fallar. No es pesimismo, es ingeniería.
Los patrones mínimos que deberían estar presentes:
- Circuit breaker: si la API devuelve errores consecutivos, para de llamar durante un intervalo configurable. No saturar un endpoint que ya está bajo presión.
- Retry con backoff exponencial: reintentos con espera creciente. Nunca reintentos inmediatos en bucle.
- Dead letter queue: los mensajes que no se pueden procesar después de N intentos deben ir a una cola de revisión, no desaparecer silenciosamente.
- Alertas sobre gaps temporales: si tu pipeline espera señales cada 30 minutos y lleva 90 sin recibir, eso debe generar una alerta antes de que alguien lo note en producción.
El punto clave es que la degradación del servicio externo no debe degradar tu arquitectura interna. El desacoplamiento no es opcional.
Antes de conectar el siguiente endpoint, documenta el contrato
Uno de los mayores problemas en equipos que crecen rápido es que las integraciones con APIs externas se construyen sin documentar el contrato de datos. ¿Qué campos son estables? ¿Cuáles pueden cambiar sin aviso? ¿Cuál es el comportamiento esperado ante queries sin resultados?
Un data contract mínimo —aunque sea un documento de una página en Notion— ahorra semanas de debugging cuando el proveedor actualiza su API en producción sin notice previo.
Define: campos garantizados, campos opcionales, rango esperado de latencia, comportamiento ante rate limit y política de versionado de la API. Si el proveedor no documenta todo esto, pregúntalo explícitamente antes de construir.
Las arquitecturas que aguantan no son las más sofisticadas. Son las que separan responsabilidades con claridad, anticipan los fallos del exterior y no mezclan la lógica de ingesta con la lógica de negocio. Eso no requiere stack complejo. Requiere disciplina de diseño antes de escribir la primera línea de código de integración.