Real-time data architecture: Kafka o REST API — la decisión correcta para LATAM

Resumen en 60 segundos

En agosto de 2025, un retailer en Lima perdió USD 68 000 durante un solo Cyber Wow. No por marketing: por arquitectura. El lead de ingeniería eligió REST API para procesar 8 000 transacciones por segundo en peak hour. Al tercer día el pipeline cayó, el dashboard de finanzas mostró ceros, y el equipo pasó dos horas sin saber si habían vendido algo. Los rescató Kafka y tres semanas de refactor. Pero los hubiera salvado una conversación con un arquitecto senior antes del lanzamiento.

La mayoría de proyectos «real-time» en LATAM hoy son pseudo-real-time: REST APIs consultados cada 30 segundos, y los data engineers lo llaman streaming. Funciona en el 80% de los casos y se rompe en el 20% restante — cuando el regulador exige validación sincrónica, cuando un retailer procesa 12 000 órdenes por minuto en Black Friday, cuando fraud detection debe disparar a 200 milisegundos en vez de 30 minutos.

Revisé más de 40 arquitecturas en LATAM en cinco años — Estée Lauder con 12 marcas, Leroy Merlin con pricing dinámico, Dodo Pizza con computer vision en cocinas, NLMK con un portal B2B para 50 000 socios. El patrón es uno: las empresas eligen Kafka cuando necesitan REST y REST cuando necesitan Kafka. Ambos errores cuestan caro — el primero en personas e infraestructura, el segundo en facturación perdida y multas regulatorias.

Este artículo es un análisis técnico sin marketing: dónde Kafka es realmente necesario, dónde es overkill, dónde REST API sigue siendo la decisión correcta en 2026, y por qué el regulatory landscape de LATAM (SUNAT, SAT con CFDI 4.0, SRI online scheme, DIAN CUFE, ARCA CAE) cambia fundamentalmente la respuesta.

• Kafka — para high-throughput streaming, event sourcing, decoupling entre 4 o más equipos, replay'ability. Setup mínimo útil: 3 brokers + Schema Registry + Kafka Connect. TCO desde USD 2 500/mes en AWS MSK para producción
• REST/gRPC API — para transacciones sincrónicas con semántica request-response, para integraciones con reguladores (SUNAT, SAT, SRI, DIAN, ARCA — todos exigen HTTP), para contratos cross-team con SLA claro
• No es Kafka si tienes menos de 1 000 events/seg y ningún requerimiento de replay — es overengineering
• No es REST si necesitas decoupling, broadcast o más de 10 consumidores del mismo evento — el synchronous fan-out mata la latencia
• El híbrido gana más a menudo que el modelo puro: REST en el borde para reguladores y partners, Kafka adentro para domain events, CDC (Debezium) para sincronizar bases de datos
• El factor LATAM: la facturación electrónica en tiempo real exige validación HTTP sub-5 segundos en SAT/SRI/DGI. Eso es territorio REST. Todo lo que pasa después — domain events, analytics, fraud — es Kafka

Por qué real-time dejó de ser opcional en LATAM

Hace tres años, real-time architecture en LATAM era «progresista». En 2026 es requerimiento regulatorio para la mitad de la industria y ventaja competitiva para el resto.

E-invoicing en tiempo real como nueva norma. Ecuador SRI opera con online scheme desde 2014: los comprobantes electrónicos se validan en horas para contribuyentes regulares y prácticamente en tiempo real para contribuyentes especiales, con devolución de la autorización en segundos. México SAT con CFDI 4.0 (obligatorio desde 2023) exige validación por PAC sincrónica, con devolución del UUID en menos de 5 segundos. Uruguay DGI con CFE 25.1 (Resolución 198/024 DGI) endureció la validación real-time. Perú SUNAT lanzó SIRE en 2024 — Sistema Integrado de Registros Electrónicos, sucesor del PLE — que opera como sistema near-real-time con envío obligatorio el día 8 de cada mes. Argentina ARCA (ex-AFIP) para facturas electrónicas exige CAE (Código de Autorización Electrónico) en tiempo real, con un máximo de 10 segundos para la aprobación.

Si tu Odoo o tu ERP se integra con un regulador fiscal, ya tienes una integración real-time vía API — te guste o no. Más contexto en la guía de Odoo para Perú y en DIAN factura electrónica 2026.

Retail y fintech subieron la presión. MercadoLibre en Hot Sale procesa picos de más de 25 000 órdenes por minuto. NuBank en 2025 reportó 110+ millones de clientes en Brasil, México y Colombia — en peak hour son más de 200 000 transacciones por segundo. Rappi opera en 9 países LATAM con decenas de miles de consultas simultáneas sobre pricing y disponibilidad de restaurantes. Estas empresas no pueden vivir sobre REST polling — construyeron plataformas de event streaming (Kafka, AWS Kinesis, GCP Pub/Sub) hace 5–7 años.

Mining, agritech y smart cities sumaron carga IoT. Codelco en Chile, Antamina en Perú, Vale en Brasil equipan camiones y maquinaria con miles de sensores que reportan telemetría a 1–10 Hz. Eso son más de 50 000 events/seg en un mining site mediano. REST API no aguanta esta carga ni con pooling ni con retry.

Las smart cities de Ciudad de México, Bogotá y Buenos Aires — sensores de tráfico, smart parking, monitoreo ambiental — todas operan sobre streaming pipelines, porque batch processing destruye la accionabilidad.

Real-time architecture en 2026 no es una decisión entre «moderno» y «tradicional». Es un set concreto de competencias sin las cuales una empresa o incumple la regulación o pierde velocidad de mercado. Para el contexto general de infraestructura LATAM, ver por qué las PYMES en LATAM pierden USD 500 mil millones al año.

Kafka y REST: capas distintas del stack

El primer error crítico de la mayoría de quienes escriben «Kafka vs API»: comparan capas distintas del stack.

Kafka es un distributed log. No es una base de datos, no es un message queue, no es un API. Es un append-only log de eventos inmutables, dividido en particiones, replicado entre brokers, accesible para lectura por muchos consumidores simultáneos con offsets independientes. El producer escribe en un topic; el consumer lee desde cualquier posición — desde el inicio de la historia, desde el momento actual, desde un offset arbitrario. La retención es configurable: 7 días por defecto, semanas o «forever» según tu presupuesto de storage. Más detalle en la documentación oficial de Apache Kafka.

Latencia de Kafka en setup production-grade:

• p50 produce latency: 2–5 ms (un solo datacenter, sin acks=all)
• p99 end-to-end (producer → consumer): 10–30 ms
• Throughput: 100 000 msg/seg en un cluster modesto de 3 brokers, millones en setup tuned
• Storage cost: ~USD 0.10/GB/mes en AWS EBS gp3 — retener un año entero es barato para la mayoría de use cases

REST API es un request-response protocol sobre HTTP. Sincrónico, blocking, point-to-point. El cliente envía un request, espera la respuesta, usa la respuesta. La descomposición: servidor HTTP, application layer (Express, FastAPI, Spring), business logic, normalmente write sincrónico a base de datos, retorno de la respuesta.

Latencia de REST API en setup production-grade:

• Intra-AZ (un solo datacenter): 5–50 ms en un endpoint simple
• Cross-region (PE → US East): 80–200 ms p50, más de 500 ms p99 con TLS handshake
• Con business logic completa y DB query: 100–500 ms típicamente

La diferencia fundamental no está en la performance. Está en la semántica del acoplamiento.

REST: producer y consumer se conocen mutuamente. El producer llama al endpoint del consumer. Si el consumer no está disponible, el producer tiene que manejar el error, hacer retry, implementar circuit breaker. Si hay muchos consumers, el producer llama a cada uno. Es tight coupling.

Kafka: producer y consumer no se conocen. El producer escribe en un topic. Puede haber 0, 1 o 100 consumers — el producer no lo sabe. Si un consumer cae, el producer no se entera. Es loose coupling con un buffer en el medio. El concepto está bien descrito en «Designing Data-Intensive Applications» de Martin Kleppmann — dataintensive.net.

Esta diferencia es fundamental. Todas las demás (latencia, throughput, complejidad) son consecuencias.

gRPC sigue siendo request-response, pero con protocol binario, HTTP/2 multiplexing y schema vía protobuf. Latencia menor que REST (no hay JSON parsing) pero la semántica es la misma: synchronous coupling. gRPC streaming se acerca a Kafka, pero sin persistencia ni multi-consumer.

GraphQL es sintaxis distinta para request-response, no es un patrón distinto. Arquitectónicamente es lo mismo que REST con composable schema. Tiene relación con real-time vía Subscriptions (normalmente WebSocket), pero eso es otra capa.

Webhooks son REST en sentido inverso: le dices al regulador o al partner que quieres recibir eventos, y ellos llaman a tu endpoint. Resuelve fan-out para 1–10 consumers, pero si son 1000, eso es territorio Kafka.

Server-Sent Events (SSE) y WebSockets sirven para streaming hacia el navegador. No son alternativa a Kafka en backend — son transport entre backend y frontend. Lo típico: el backend lee de Kafka y empuja al navegador vía SSE.

Cuando alguien dice «Kafka vs API» normalmente quiere decir «event-streaming vs request-response». Y esa no es una comparación de «o uno o el otro», sino de «uno más el otro». Las arquitecturas reales usan ambos: REST para contratos cross-team, Kafka para flujo interno de eventos, CDC (Change Data Capture vía Debezium) para sincronizar cambios de base de datos en Kafka.

Cinco escenarios reales: qué funciona y qué no

Cinco situaciones que aparecen en cualquier auditoría de arquitectura en LATAM. Qué usar y por qué.

#1. Integración con SUNAT, SAT, SRI o DIAN para e-invoicing

Esto es REST. Punto. El regulador exige validación HTTP sincrónica con devolución de XML firmado en menos de 5 segundos. Kafka aquí es inútil — el regulador no tiene Kafka consumer, tú no tienes streaming integration directo con el Estado. Lo que sí puedes hacer: meter el evento invoice_emitted en Kafka después de la respuesta exitosa del REST a SAT/PAC, para que otros 12 servicios (analytics, notificación al cliente, accounting reconciliation) reaccionen de forma asíncrona. La llamada primaria al regulador es REST.

#2. Pricing intelligence para retail

Supongamos que manejas 12 marcas de beauty, monitoreas 8 marketplaces y mueves precios dinámicamente. Esto es territorio Kafka, pero con REST en los bordes. Los web scrapers escriben eventos competitor_price_changed en un topic con throughput de 5 000–20 000 events/min. El pricing engine consume, calcula el precio óptimo vía ML model, escribe en price_recommendation. Varios consumers la toman: uno empuja al e-commerce vía REST API del marketplace, otro notifica a los merchandisers, un tercero escribe al data warehouse. Si tienes 1 marketplace y 50 SKUs, Kafka es overkill — REST polling cada hora funciona.

#3. Fraud detection en fintech

NuBank, Belvo, Bitso — todos construyen fraud detection sobre event streaming. Las transacciones se evalúan en 200–500 ms; si no, la UX sufre. Acá Kafka + stream processing (Flink o ksqlDB) es el estándar. REST mata la latencia: llamada al modelo, llamada al rules engine, llamada a graph database para relaciones — son 4 HTTP calls sequenciales, 400 ms en la mejor infraestructura. Si tienes 50 transacciones al día, ¿a quién le importa que el fraud check tome 5 segundos? REST.

#4. IoT real-time para mining o agritech

Una mina con 500 camiones, 50 excavadoras y 200 sensores por unidad son 50 000 events/seg — y eso es solo telemetría operacional, sin contar production data. REST físicamente no aguanta — el pool de TCP connections revienta. Kafka (o Kinesis o GCP Pub/Sub) es obligatorio. Los producers escriben en topics particionados por equipment_id; los consumers son predictive maintenance models, dashboards, alerting. Si tienes 5 sensores en 1 finca, escribe en Postgres vía REST y no inventes.

#5. Portal B2B con notificaciones a partners

NLMK lanzó un portal B2B para 50 000 partners — estado de órdenes, actualización de inventario, document workflow. Por dentro: arquitectura event-driven con domain events (order_created, invoice_sent, delivery_scheduled) en Kafka. Por fuera: REST API para cada partner, porque los partners son external integrators con sus propios sistemas y no se van a conectar a tu Kafka. Híbrido: Kafka adentro, REST en el borde. Es el modelo por defecto para enterprise platforms modernas.

Una regla simple para la arquitectura de datos en LATAM: la frontera entre organizaciones es REST. La frontera entre servicios dentro de una organización es Kafka (o async). La frontera con el regulador es siempre REST. La frontera con la base de datos vía CDC es Kafka.

Cinco errores típicos en cada segunda auditoría

Patrones que se repiten en empresas de Lima, Bogotá, Ciudad de México y Buenos Aires. Cada uno cuesta entre USD 10 000 y USD 500 000 al año en ingeniería desperdiciada o ingresos perdidos.

#1. Kafka para cada integración

El equipo lee «Designing Data-Intensive Applications», se enamora del event streaming y mete Kafka entre todo. Resultado: un simple GET /user/{id} pasa por 3 topics con response-paired, la latencia sube de 50 ms a 800 ms, los ingenieros debuguean esto durante meses. En una auditoría reciente (anonimizada, fintech en Lima) un equipo de 8 personas dedicaba 40% del tiempo a operaciones de Kafka — son USD 480 000/año de capacidad perdida para feature work.

Solución: Kafka solo donde haya decoupling value real — 3 o más consumers, replay'ability, throughput superior a 5 000 events/seg, requerimiento de event sourcing.

#2. REST para streaming

La crítica inversa. El equipo quiere un dashboard «real-time» y consulta un endpoint cada segundo. Con 100 usuarios son 100 req/seg; con 10 000 son 10k req/seg y el backend se cae. En un retailer de Bogotá perdieron USD 34 000 en una semana de Cyber Days porque el dashboard consultaba cada 500 ms y se comió todo el API quota.

Solución: para real-time UI usa WebSocket o SSE en el frontend, y Kafka consumer + push en el backend.

#3. Sin Schema Registry

Kafka sin Schema Registry es una bomba de tiempo. El producer escribe JSON sin contrato, una semana después cambia un campo, el consumer downstream cae en producción un sábado. En un e-commerce de México esto resultó en 6 horas de downtime de reportería, USD 12 000 en decisiones perdidas de merchandisers y tres semanas de forensics para entender quién y cuándo cambió el schema.

Solución: Confluent Schema Registry o Apicurio desde el día uno. Avro o Protobuf como schema format, JSON Schema como mínimo. Schema evolution rules (backward, forward) configuradas e inforzadas en CI.

#4. Un solo topic para todo

Equipos crean un topic events, escriben todo ahí, y después se sorprenden de que 200 consumers filtren 99% de los mensajes. Anti-pattern que destruye scalability.

Solución: un topic por domain event type, partition key por entity ID. Compaction para state changes, retention según compliance (en finance, 7 años mínimo, ver requerimientos PLE/SIRE en Perú).

#5. Ignorar idempotency

REST API sin idempotency keys por defecto: transacciones dobles en retry, duplicados en base de datos, violaciones regulatorias. Kafka producers sin enable.idempotence=true: duplicados en el topic, rotura de exactly-once semantics. En un PSP (Payment Service Provider) en Argentina encontré 0.3% de double-charges en seis meses — más de USD 200 000 en chargebacks y pérdidas operativas.

Solución: idempotency keys en todos los endpoints mutables (UUID v4 en el header Idempotency-Key), Kafka con enable.idempotence=true + acks=all + min.insync.replicas=2 para exactly-once.

Caso anónimo: retailer LATAM con 12 marcas

Cliente portfolio anonimizado por contrato, descrito públicamente en materiales de Forbes como Estée Lauder Travel Retail: retailer con 12 marcas, 8 marketplaces, necesidad de mover precios dinámicamente y lanzar promos mientras los competidores se movían en tiempo real.

Estado inicial: REST API entre el ERP y cada marketplace, batch update cada 6 horas, ROAS de marketing en 1.5x — porque los precios envejecían 6 horas y el ad spend iba a productos que el competidor ya tenía más baratos.

Qué hicimos:

1. Levantamos un cluster Kafka (Confluent Cloud, 3 brokers, ~USD 3 200/mes — más barato que self-managed al inicio)
2. Los web scrapers (Scrapy + Playwright) escriben eventos competitor_price_change con throughput de ~12 000 events/hora
3. El pricing engine en Python + LightGBM consume, calcula la recommendation, escribe en el topic price_recommendation
4. REST bridges hacia las APIs de los marketplaces toman las recommendations y hacen update calls sincrónicos (siguen siendo REST porque Mercado Libre, Linio y Falabella no exponen Kafka endpoints)
5. Schema Registry con Avro, backward-compatibility rules, CI gates

Resultado a 6 meses:

Detalle importante: REST no se eliminó. Entre Kafka y los marketplaces se mantuvieron los REST bridges porque son external integrations. Híbrido. Esa es la norma para enterprise LATAM, y la base de cualquier caso de transformación que publicamos.

Cinco preguntas antes de elegir arquitectura

Antes de pedirle al equipo «metamos Kafka» o «pongamos REST API en todo», responde estas 5 preguntas:

1. Throughput por tipo de evento: events/seg — ¿lo mediste o lo estás adivinando?
2. Consumer count por evento: ¿1, 5 o 50?
3. Replay requirement: ¿necesitas revisar la historia del último mes o año?
4. Integraciones regulatorias: SUNAT, SAT, SRI, DIAN, ARCA — todos tienen REST endpoints, y punto
5. Engineering capacity: ¿alguien en el equipo se levanta a las 3 a.m. a arreglar Kafka offset issues?

Si en 3 o más preguntas la respuesta es «no sé», necesitas una auditoría antes de las decisiones arquitectónicas, no después.

El veredicto: la decisión «Kafka vs API» no es ideológica. Es una decisión de ingeniería sobre 5 parámetros — throughput, consumers, replay, restricciones regulatorias, capacidad del equipo. En LATAM se le agrega un nivel extra: los reguladores fiscales exigen REST, la facturación electrónica real-time es una frontera REST obligatoria, Kafka vive adentro de la organización.

Si eliges arquitectura para un producto real-time nuevo en LATAM en 2026, el default es híbrido: REST en el borde (con reguladores, partners, frontend vía WebSocket o SSE), Kafka adentro (domain events, analytics, audit log), CDC entre base de datos y Kafka. REST puro funciona en proyectos con throughput inferior a 1k events/seg sin replay. Kafka puro funciona en pure data platforms sin external integrations, lo cual en LATAM casi no existe.

El error más caro es seguir la moda. He visto startups de 5 personas con un Kafka cluster de USD 5 000/mes que mueve 50 events por hora. Y he visto enterprises que en 2026 todavía hacen batch ETL, perdiendo dinero real en datos obsoletos.

Si tienes un Odoo o un ERP que creció más allá del CRUD simple y estás pensando en real-time analytics, real-time fraud detection o real-time pricing, pide una auditoría de 30 minutos. Te decimos honestamente si necesitas Kafka o no.

Preguntas frecuentes