Entrevista de ingeniería de datos: ¿Kinesis on-demand o capacidad aprovisionada?

Planteamiento y contexto

Usted es responsable de una plataforma de datos que ingiere eventos de usuarios para varios consumidores en tiempo real. El tráfico es estable la mayor parte del día y presenta picos durante las campañas. El negocio no puede tolerar una limitación de tasa (throttling) sostenida, pero no desea pagar por adelantado capacidad para los periodos de baja actividad. Asuma que puede leer el rendimiento del productor, la latencia de lectura, el throttling y el retraso del consumidor (consumer lag), y que puede cambiar el modo de capacidad durante una ventana de mantenimiento.

Qué evalúa el entrevistador

El entrevistador está evaluando si comprende que el modo de capacidad cambia la responsabilidad operativa y el costo, no la semántica de entrega. Una respuesta sólida utiliza los picos históricos y el perfil de las ráfagas para decidir si el escalado automático aporta valor, y luego verifica los límites por partición (shard), la cantidad de consumidores, los reintentos y la recuperación del retraso. Una respuesta débil simplemente dice que se elija on-demand siempre que el tráfico varíe.

Aclaraciones que conviene hacer primero

• ¿Cuánto duran los picos y son predecibles? Los picos cortos e impredecibles favorecen la gestión automatizada de la capacidad.
• ¿Están limitadas las escrituras y las lecturas al mismo tiempo? Mida los bytes, los registros, las lecturas y el comportamiento de los consumidores por separado.
• ¿Existe un límite máximo estricto de costos o un presupuesto de capacidad? El tráfico estable con un presupuesto ajustado es más fácil de optimizar en modo aprovisionado.
• ¿Los consumidores comparten el rendimiento o necesitan lecturas dedicadas? Múltiples consumidores modifican las cuotas de lectura y los costos.
• ¿Puede el equipo tolerar una breve transición de estado? El cambio de modo y los reintentos por ráfagas requieren un procedimiento operativo (runbook) explícito.

Estructura de respuesta en 30 segundos

“Mediría los MB/s de escritura por hora, la tasa de registros, los MB/s de lectura, el lag y el throttling, separando los picos predecibles de las ráfagas. El tráfico estable y predecible puede utilizar capacidad aprovisionada con un cronograma de escalado; los cambios rápidos o impredecibles favorecen on-demand, pero validaría el incremento gradual (ramp-up), las cuotas y el costo. Cualquiera de las dos opciones debe cumplir con las salvaguardas de throttling, recuperación de lag, latencia de extremo a extremo y gasto mensual.”

Respuesta detallada paso a paso

1. Construir una línea base de capacidad. Agregue escrituras y lecturas por minuto, registre P50, P95, P99, duración del pico y claves de partición sobrecargadas (hot partition keys); los promedios ocultan las ráfagas.
2. Verificar los límites de rendimiento. AWS documenta un límite de shard predeterminado de 1 MB/s o 1,000 registros por segundo para escrituras y 2 MB/s para lecturas. Convierta el tamaño de los registros y el procesamiento por lotes tanto a bytes como a registros.
3. Elegir un modo. Utilice capacidad aprovisionada con un plan de escalado para cargas estables; prefiera on-demand cuando la carga cambie rápidamente o sea difícil de predecir, y registre la latencia de ajuste automático.
4. Modelar los consumidores. Las lecturas compartidas, enhanced fan-out, los reintentos y el procesamiento de duplicados afectan las cuotas de lectura. El lag del consumidor pertenece a la planificación de capacidad, no solo las métricas del productor.
5. Modelar el costo. Para el modo aprovisionado, incluya shard-hours y el margen de seguridad para escalado. Para on-demand, incluya el rendimiento real y la facturación por picos, además de la reproducción (replay) y las escrituras dobles por ráfagas.
6. Hacer una prueba piloto y revertir. Cambie un flujo no crítico, observe el throttling, la recuperación del lag, la latencia P99 y el gasto mensual. Si una salvaguarda falla, regrese al modo validado preservando el orden y el comportamiento de reintentos.

Las alternativas incluyen dividir las claves de partición sobrecargadas, agrupar escrituras en lotes, reducir el tamaño de los eventos, almacenar en búfer con Firehose o preescalar para campañas predecibles. El modo de capacidad no puede solucionar claves desbalanceadas, consumidores lentos ni reintentos infinitos.

Respuesta modelo

“Inspeccionaría 30 días de curvas de escritura y lectura por minuto, calcularía P95/P99, la duración de los picos y el sesgo de las claves de partición. Traduciría el tamaño de los registros mediante los límites de shard de AWS a MB/s de escritura y tasa de registros, y luego verificaría el rendimiento compartido de los consumidores y la recuperación del lag. Para picos predecibles que duran horas, usaría capacidad aprovisionada y preescalaría antes de las campañas. Para picos cortos e impredecibles, realizaría una prueba piloto de on-demand en un flujo no crítico con un throttling inferior al 0.1%, un p99 de recuperación de lag menor a 5 minutos, latencia de extremo a extremo dentro del 20% respecto a la línea base y un límite de costo mensual. Monitorearía particiones sobrecargadas y duplicados en ambos modos; cambiar el modo de capacidad no debe ocultar la causa raíz.”

Errores comunes

• Error: Estimar a partir del rendimiento promedio → Por qué falla: Las ráfagas y las claves sobrecargadas causan throttling local → Solución: Utilizar P95/P99, duración del pico y distribución de claves.
• Error: Tratar on-demand como rendimiento ilimitado → Por qué falla: Las cuotas del servicio y el incremento gradual siguen importando → Solución: Validar el comportamiento del ramp-up, las cuotas y las pruebas de ráfagas.
• Error: Contabilizar solo el costo del productor → Por qué falla: Los consumidores, los reintentos y el replay amplifican el rendimiento → Solución: Construir escenarios de costos de extremo a extremo.
• Error: Ignorar la semántica de entrega → Por qué falla: El modo de capacidad no elimina los riesgos de entrega al menos una vez (at-least-once) ni de procesamiento de duplicados → Solución: Mantener la idempotencia, los puntos de control (checkpoints) y la recuperación de lag.

Preguntas de seguimiento y respuestas

On-demand todavía sufre throttling; ¿qué ajusta primero?

Separe la falta de rendimiento total, las claves de partición sobrecargadas y un consumidor rezagado. Verifique la tasa de registros, la distribución de claves y los eventos de escalado antes de optar por backoff, reparticionamiento o más consumidores.

¿Cuándo es más barata la capacidad aprovisionada?

Cuando las escrituras y lecturas son estables, los picos pueden programarse y la utilización se mantiene alta, modele las shard-hours y el margen de escalado. No compare únicamente el precio unitario.

¿Qué pasa si el tráfico de una campaña se multiplica por diez?

Verifique primero las cuotas de on-demand y el comportamiento histórico de ramp-up. Preescale las campañas predecibles, agregue backoff en productores y alertas de lag, y defina degradación para eventos no críticos.

¿Cómo demuestra que la elección es correcta?

Compare throttling, p99 de recuperación de lag, latencia de extremo a extremo, tasa de duplicados y costo mensual antes y después del piloto con las mismas definiciones. Expanda después de que dos ciclos comerciales cumplan con las salvaguardas.