DEV Community: Hazel Saenz

Multi-step workflows que sobreviven fallos

Hazel Saenz — Thu, 23 Apr 2026 23:23:14 +0000

Cómo los checkpoints automáticos en Lambda Durable Functions mantienen tu progreso incluso cuando todo se rompe.

En el artículo anterior construimos una Durable Function de procesamiento de imágenes paso a paso. Instalamos el Kiro Power, generamos el código con IA, testeamos localmente, y deployamos a AWS con CDK.

Todo funcionó perfecto.

Y ese es el problema.

En producción, las cosas se rompen. APIs que no responden, timeouts, servicios caídos, datos corruptos. La pregunta no es si algo va a fallar, sino cuándo.

La promesa central de Durable Functions es que tu workflow sobrevive a los fallos sin perder progreso. Pero, ¿cómo funciona eso realmente? ¿Qué pasa cuando un step falla a mitad de ejecución? ¿Cómo sabe la función dónde retomar?

En este artículo vamos a romper cosas a propósito. Vamos a simular fallos reales, ver cómo el replay model recupera la ejecución, configurar estrategias de reintento, y aprender a manejar errores dentro del contexto durable.

Mismo proyecto de procesamiento de imágenes. Pero esta vez, en modo destrucción.

El replay model por dentro

En el artículo anterior mencionamos que cada context.step() es un checkpoint. Pero no explicamos qué pasa por debajo. Ahora sí.

Cuando una Durable Function se ejecuta por primera vez, el flujo es lineal:

Entra el evento
Ejecuta el Step 1 → guarda el resultado como checkpoint
Ejecuta el Step 2 → guarda el resultado como checkpoint
Ejecuta el Step 3 → guarda el resultado como checkpoint
Retorna el resultado final

Hasta aquí, nada especial. Parece una función normal.

Pero ahora imagina que el Step 3 falla. Un timeout, un error de red, lo que sea. La función se cae.

Cuando la función se reintenta (ya sea por el retry automático de Lambda o por una nueva invocación), esto es lo que pasa:

Entra el evento (el mismo)
Llega al Step 1 → ya tiene checkpoint → salta la ejecución, usa el resultado guardado
Llega al Step 2 → ya tiene checkpoint → salta la ejecución, usa el resultado guardado
Llega al Step 3 → no tiene checkpoint → lo ejecuta de nuevo
Si funciona → guarda checkpoint → continúa
Si falla otra vez → repite el ciclo

Eso es el replay model. No es magia. Es un sistema de checkpoints que guarda el resultado de cada step y lo reutiliza en los reintentos.

Lo importante: el código se ejecuta desde el principio cada vez. Pero los steps que ya completaron se saltan instantáneamente porque el resultado ya está guardado. El código fuera de los steps sí se vuelve a ejecutar (por eso la regla de oro del determinismo que vimos en el artículo anterior).

Anatomía de un checkpoint

¿Qué se guarda exactamente en cada context.step()?

Cada checkpoint almacena:

El nombre del step: el string que le pasas como primer argumento ('validate-file', 'resize-image', etc.)
El resultado: lo que retorna la función async dentro del step
El estado: completado, fallido, o en progreso
Timestamps: cuándo empezó y cuándo terminó

// Cuando este step se completa exitosamente...
const validated = await context.step('validate-file', async () => {
  const metadata = await sharp(buffer).metadata();
  return {
    format: metadata.format,
    width: metadata.width,
    height: metadata.height,
    size: buffer.length
  };
});

// ...el checkpoint guarda algo como:
// {
//   name: 'validate-file',
//   status: 'completed',
//   result: { format: 'jpeg', width: 1920, height: 1080, size: 2456789 },
//   startedAt: '2026-04-20T10:00:00.000Z',
//   completedAt: '2026-04-20T10:00:01.234Z'
// }

Consideraciones sobre el tamaño de los datos

El resultado de cada step se serializa y se guarda. Eso significa que si tu step retorna un buffer de 5 MB, esos 5 MB se guardan en el checkpoint.

Recuerda que Durable Functions maneja datos entre pasos a través de checkpoints serializados. La documentación oficial recomienda mantener el estado mínimo y usar almacenamiento externo (S3, DynamoDB) para datos grandes. No es infinito.

Buena práctica: retorna solo lo que el siguiente step necesita. Si procesaste una imagen, no retornes el buffer completo. Guárdalo en S3 y retorna la key.

// ❌ Esto puede ser problemático con imágenes grandes
const imageBuffer = await context.step('resize', async () => {
  const resized = await sharp(buffer).resize(1920, 1080).toBuffer();
  return resized.toString('base64'); // Puede ser varios MB
});

// ✅ Mejor: guarda en S3 y retorna la referencia
const resizedKey = await context.step('resize', async () => {
  const resized = await sharp(buffer).resize(1920, 1080).toBuffer();
  const key = `processed/${baseName}-resized${ext}`;
  await s3.send(new PutObjectCommand({
    Bucket: outputBucket,
    Key: key,
    Body: resized,
  }));
  return key; // Solo unos bytes
});

Rompiendo cosas a propósito — Escenario 1: Fallo transitorio

Basta de teoría. Vamos a romper algo.

Usaremos el mismo proyecto de procesamiento de imágenes del artículo anterior. Si no lo tienes, puedes clonarlo desde GitHub.

Simulando un fallo de red en el resize

Vamos a modificar el step de resize para que falle las primeras dos veces, simulando un error de red transitorio:

// Contador de intentos (solo para demostración)
let resizeAttempts = 0;

const resizedBase64 = await context.step('resize-image', async () => {
  resizeAttempts++;

  // Simular fallo de red en los primeros 2 intentos
  if (resizeAttempts <= 2) {
    context.logger.error(`Resize attempt ${resizeAttempts} failed - simulating network error`);
    throw new Error('ENETUNREACH: network is unreachable');
  }

  context.logger.info(`Resize attempt ${resizeAttempts} succeeded`);

  const buffer = Buffer.from(imageBuffer, 'base64');
  const resized = await sharp(buffer)
    .resize(1920, 1080, { fit: 'inside', withoutEnlargement: true })
    .toBuffer();

  const resizedKey = `${outputPrefix}/${baseName}-resized${ext}`;
  await s3.send(new PutObjectCommand({
    Bucket: outputBucket,
    Key: resizedKey,
    Body: resized,
    ContentType: `image/${ext.replace('.', '')}`,
  }));

  return resized.toString('base64');
});

Qué pasa cuando lo ejecutas

Invoca la función:

aws lambda invoke \
  --function-name 'TU-FUNCION:prod' \
  --invocation-type RequestResponse \
  --durable-execution-name "test-failure-$(date +%s)" \
  --payload '{"bucket":"TU-BUCKET","key":"photos/test.jpg"}' \
  --cli-binary-format raw-in-base64-out \
  response.json

En los logs de CloudWatch vas a ver algo como esto:

2026-04-23T10:00:00.000Z [INFO] Step 'validate-file' - executing
2026-04-23T10:00:01.234Z [INFO] File validated: jpeg, 1920x1080, 2.4MB
2026-04-23T10:00:01.235Z [INFO] Step 'validate-file' - completed ✓
2026-04-23T10:00:01.300Z [INFO] Step 'resize-image' - executing
2026-04-23T10:00:01.301Z [ERROR] Resize attempt 1 failed - simulating network error
2026-04-23T10:00:02.500Z [INFO] Step 'resize-image' - retrying (attempt 2)
2026-04-23T10:00:02.501Z [ERROR] Resize attempt 2 failed - simulating network error
2026-04-23T10:00:04.800Z [INFO] Step 'resize-image' - retrying (attempt 3)
2026-04-23T10:00:05.120Z [INFO] Resize attempt 3 succeeded
2026-04-23T10:00:05.121Z [INFO] Step 'resize-image' - completed ✓
2026-04-23T10:00:05.200Z [INFO] Step 'apply-watermark' - executing
...

Fíjate en lo que no aparece: no hay un segundo Step 'validate-file' - executing. El step de validación se completó en el primer intento, se guardó el checkpoint, y en los reintentos del resize no se volvió a ejecutar.

Eso es el replay model haciendo su trabajo. El progreso no se pierde.

Estrategias de reintento

En el ejemplo anterior, el SDK reintentó automáticamente. Pero en producción necesitas control fino sobre cómo y cuándo reintentar.

Cada step acepta un retryStrategy que te permite configurar. El SDK provee un helper createRetryStrategy() para construir estrategias con configuración declarativa:

import { createRetryStrategy, JitterStrategy } from '@aws/durable-execution-sdk-js';

const retryStrategy = createRetryStrategy({
  maxAttempts: 5,                    // Total de intentos (incluyendo el primero)
  initialDelay: { seconds: 1 },     // Espera inicial: 1 segundo
  backoffRate: 2,                    // Multiplica el tiempo de espera entre reintentos: 1s → 2s → 4s → 8s
  maxDelay: { seconds: 30 },        // Tope máximo: 30 segundos
  jitter: JitterStrategy.FULL,      // Variación aleatoria 
});

También puedes escribir una estrategia custom como función directa:

const result = await context.step('call-api', async () => callAPI(), {
  retryStrategy: (error, attemptCount) => {
    if (attemptCount >= 5) return { shouldRetry: false };
    const delay = Math.min(2 * Math.pow(2, attemptCount - 1), 30);
    return { shouldRetry: true, delay: { seconds: delay } };
  }
});

Exponential backoff: por qué importa

Si un servicio está caído y reintentamos inmediatamente, lo único que logramos es bombardearlo con requests mientras intenta recuperarse. Es como tocar el timbre 50 veces cuando alguien no abre la puerta.

El exponential backoff resuelve esto: cada reintento espera más que el anterior.

Intento 1: falla → espera 1 segundo
Intento 2: falla → espera 2 segundos
Intento 3: falla → espera 4 segundos
Intento 4: falla → espera 8 segundos
Intento 5: falla → se rinde

Esto le da tiempo al servicio para recuperarse sin ahogarlo con requests.

Aplicando retry strategy al step de watermark

const watermarked = await context.step(
  'apply-watermark',
  async () => {
    const buffer = Buffer.from(resizedBase64, 'base64');

    // Llamada a un servicio externo de watermark
    const response = await fetch('https://watermark-api.example.com/apply', {
      method: 'POST',
      body: buffer,
      headers: { 'Content-Type': 'application/octet-stream' },
    });

    if (!response.ok) {
      throw new Error(`Watermark API failed: ${response.status}`);
    }

    const watermarkedBuffer = Buffer.from(await response.arrayBuffer());
    const watermarkedKey = `${outputPrefix}/${baseName}-watermarked${ext}`;

    await s3.send(new PutObjectCommand({
      Bucket: outputBucket,
      Key: watermarkedKey,
      Body: watermarkedBuffer,
    }));

    return watermarkedKey;
  },
  {
    retryStrategy: createRetryStrategy({
      maxAttempts: 5,
      initialDelay: { seconds: 2 },
      backoffRate: 2,
      maxDelay: { seconds: 30 },
    })
  }
);

Qué errores reintentar y cuáles no

No todos los errores merecen un reintento. Si el servicio devuelve un 404 Not Found, reintentarlo 5 veces no va a cambiar nada. Pero un 503 Service Unavailable sí puede resolverse con tiempo.

Regla general:

Error	¿Reintentar?	Por qué
Timeout / ENETUNREACH	✅	Problema de red transitorio
429 Too Many Requests	✅	Rate limiting, esperar ayuda
500 Internal Server Error	✅	El servidor puede recuperarse
503 Service Unavailable	✅	Servicio temporalmente caído
400 Bad Request	❌	Los datos están mal, reintentar no cambia nada
404 Not Found	❌	El recurso no existe
403 Forbidden	❌	No tienes permisos
Formato de archivo inválido	❌	El archivo no va a cambiar

Para errores que no deberían reintentarse, puedes lanzar un error específico y manejarlo con try/catch (lo vemos en el siguiente escenario).

Rompiendo cosas a propósito — Escenario 2: Fallo permanente

No todos los fallos se resuelven reintentando. A veces el archivo está corrupto, el formato no es soportado, o los datos de entrada son inválidos. Reintentar 100 veces no va a arreglar un PNG roto.

Para estos casos necesitas manejo de errores explícito con try/catch y lógica de compensación. El enfoque más robusto es envolver los steps que pueden fallar permanentemente en un try/catch y ejecutar la compensación en un step separado:

Simulando un archivo corrupto

export const handler = withDurableExecution(async (event: ImageEvent, context: DurableContext) => {
  const outputBucket = event.outputBucket ?? event.bucket;
  const outputPrefix = event.outputPrefix ?? 'processed';
  const baseName = event.key.replace(/\.[^.]+$/, '');
  const ext = event.key.match(/\.[^.]+$/)?.[0] ?? '.jpg';

  let imageBuffer: string;

  try {
    // Step 1: Validar el archivo
    imageBuffer = await context.step('validate-file', async () => {
      const response = await s3.send(new GetObjectCommand({
        Bucket: event.bucket,
        Key: event.key,
      }));

      if (!response.Body) {
        throw new Error(`File not found: ${event.key}`);
      }

      const buffer = Buffer.from(await response.Body.transformToByteArray());
      const metadata = await sharp(buffer).metadata();

      if (!metadata.format || !['jpeg', 'png', 'webp', 'tiff'].includes(metadata.format)) {
        throw new Error(
          `Unsupported image format: ${metadata.format}. Supported: jpeg, png, webp, tiff`
        );
      }

      return buffer.toString('base64');
    });

  } catch (error) {
    // Compensación: notificar y limpiar
    await context.step('handle-validation-failure', async () => {
      context.logger.error('Validation failed, executing compensation', {
        error: (error as Error).message,
        key: event.key,
      });

      // Notificar al usuario
      await sns.send(new PublishCommand({
        TopicArn: process.env.NOTIFICATION_TOPIC_ARN,
        Subject: 'Image Processing Failed',
        Message: JSON.stringify({
          status: 'failed',
          reason: (error as Error).message,
          key: event.key,
          timestamp: new Date().toISOString(),
        }),
      }));

      // Mover el archivo a una carpeta de errores para revisión
      await s3.send(new CopyObjectCommand({
        Bucket: event.bucket,
        CopySource: `${event.bucket}/${event.key}`,
        Key: `errors/${event.key}`,
      }));
    });

    return {
      status: 'failed',
      reason: (error as Error).message,
      key: event.key,
    };
  }

  // Si llegamos aquí, la validación pasó. Continuar con el procesamiento...
  const resizedBase64 = await context.step('resize-image', async () => {
    // ... resize logic
  });

  // ... resto del workflow
});

Qué está pasando aquí

El step validate-file detecta que el formato no es soportado y lanza un error
El error no se reintenta porque es un fallo permanente (el archivo no va a cambiar)
El catch ejecuta un step de compensación: handle-validation-failure
La compensación notifica al usuario vía SNS y mueve el archivo a una carpeta de errores
La función retorna un resultado de fallo limpio

Fíjate que la compensación también está dentro de un context.step(). Esto es importante: si la función se cae mientras envía la notificación, el replay model se encarga de que no se pierda.

El patrón de compensación

La compensación es el "plan B" cuando algo falla de forma irrecuperable. No es solo loggear el error y seguir adelante. Es deshacer o mitigar el impacto del fallo.

Ejemplos de compensación:

Fallo	Compensación
Procesamiento de imagen falla	Notificar al usuario, mover archivo a revisión
Cobro duplicado	Emitir reembolso automático
Envío de email falla permanentemente	Registrar en cola de dead letters, alertar al equipo
Creación de recurso falla a mitad	Eliminar recursos parcialmente creados

La clave: cada step de compensación debe ser idempotente (ya llegaremos a eso). Si la compensación se ejecuta dos veces, el resultado debe ser el mismo.

Errores fuera de los steps

Hay un caso que confunde a muchos: ¿qué pasa cuando el error ocurre fuera de un context.step()?

export const handler = withDurableExecution(async (event: ImageEvent, context: DurableContext) => {
  // ⚠️ Este código está FUERA de un step
  const config = JSON.parse(event.config); // Si event.config no es JSON válido... 💥

  const validated = await context.step('validate-file', async () => {
    // ...
  });
});

Si JSON.parse falla, la función se cae antes de llegar a cualquier step. No hay checkpoint. No hay replay. No hay recuperación elegante.

Según la documentación oficial: cuando un error ocurre fuera de un step, el SDK marca la ejecución como FAILED y no la reintenta automáticamente. La ejecución termina ahí. No hay loop infinito de reintentos, pero tampoco hay recuperación. Tu workflow simplemente muere.

La regla: todo lo que puede fallar va dentro de un step

export const handler = withDurableExecution(async (event: ImageEvent, context: DurableContext) => {
  // ✅ Ahora el parseo está dentro de un step
  const config = await context.step('parse-config', async () => {
    try {
      return JSON.parse(event.config);
    } catch {
      // Retornar config por defecto si el parseo falla
      context.logger.warn('Invalid config, using defaults');
      return { maxWidth: 1920, maxHeight: 1080, quality: 80 };
    }
  });

  const validated = await context.step('validate-file', async () => {
    // ...
  });
});

Ahora si el parseo falla, el step lo maneja con un fallback. Y si la función se reintenta después de que este step completó, el resultado (ya sea el config parseado o el default) ya está en el checkpoint.

Regla práctica: si una línea de código puede lanzar una excepción, debería estar dentro de un step. El código fuera de los steps debe ser puramente determinístico: asignaciones simples, cálculos con datos del evento, cosas que nunca fallan.

¿Qué es idempotencia?

Antes de hablar de por qué la idempotencia importa en Durable Functions, hay que entender el concepto.

Una operación es idempotente cuando ejecutarla una vez produce exactamente el mismo resultado que ejecutarla múltiples veces con los mismos inputs.

Suena abstracto. Vamos con ejemplos.

La analogía del elevador

Presionas el botón del elevador. El elevador viene. Presionas el botón 10 veces más. El elevador sigue viniendo una sola vez. No vienen 11 elevadores.

Presionar el botón del elevador es una operación idempotente.

Ahora imagina un botón de "comprar" en una tienda online. Lo presionas una vez: se cobra $10. Lo presionas otra vez: se cobran otros $10. Ahora debes $20 por un solo producto.

Presionar el botón de comprar no es idempotente (a menos que lo diseñes para que lo sea).

En software

Algunas operaciones son naturalmente idempotentes:

// ✅ PUT: actualizar un registro con los mismos datos siempre da el mismo resultado
await dynamodb.send(new PutItemCommand({
  TableName: 'users',
  Item: { userId: { S: '123' }, name: { S: 'Ana' }, email: { S: 'ana@example.com' } }
}));
// Ejecutar esto 1 vez o 100 veces → el registro queda igual

// ✅ DELETE por ID: eliminar algo que ya no existe no causa error
await s3.send(new DeleteObjectCommand({
  Bucket: 'my-bucket',
  Key: 'photos/test.jpg'
}));
// Ejecutar esto 1 vez o 100 veces → el archivo no está

// ✅ Escribir en S3 con la misma key: sobrescribe con el mismo contenido
await s3.send(new PutObjectCommand({
  Bucket: 'my-bucket',
  Key: 'processed/photo-resized.jpg', // Key fija y determinística
  Body: resizedBuffer,
}));
// Ejecutar esto 1 vez o 100 veces → el mismo archivo en la misma ubicación

Otras operaciones requieren diseño explícito para ser idempotentes:

// ❌ INSERT: cada ejecución crea un registro nuevo
await dynamodb.send(new PutItemCommand({
  TableName: 'orders',
  Item: {
    orderId: { S: crypto.randomUUID() }, // ID diferente cada vez
    amount: { N: '10' }
  }
}));
// Ejecutar 3 veces → 3 órdenes diferentes. Desastre.

// ❌ Envío de email: cada ejecución envía un email nuevo
await ses.send(new SendEmailCommand({
  Destination: { ToAddresses: ['user@example.com'] },
  Message: { Subject: { Data: 'Tu orden fue procesada' }, Body: { Text: { Data: '...' } } }
}));
// Ejecutar 3 veces → 3 emails. El usuario piensa que tiene 3 órdenes.

// ❌ Cobro: cada ejecución cobra de nuevo
await stripe.charges.create({ amount: 1000, currency: 'usd', source: token });
// Ejecutar 3 veces → 3 cobros de $10. El usuario paga $30.

Cómo hacer idempotente lo que no lo es

El patrón más común es usar una idempotency key: un identificador único que garantiza que la operación solo se ejecuta una vez.

// ✅ INSERT con idempotency key
const orderId = `order-${event.userId}-${event.timestamp}`; // Determinístico

await dynamodb.send(new PutItemCommand({
  TableName: 'orders',
  Item: {
    orderId: { S: orderId }, // Siempre el mismo para el mismo input
    amount: { N: '10' }
  },
  ConditionExpression: 'attribute_not_exists(orderId)', // Solo inserta si no existe
}));

// ✅ Cobro con idempotency key
await stripe.charges.create({
  amount: 1000,
  currency: 'usd',
  source: token,
  idempotencyKey: `charge-${event.userId}-${event.orderId}`, // Stripe ignora duplicados
});

// ✅ Email con deduplicación
const emailId = `email-${event.orderId}-confirmation`;
const alreadySent = await checkIfEmailSent(emailId); // Consulta a DynamoDB
if (!alreadySent) {
  await ses.send(new SendEmailCommand({ /* ... */ }));
  await markEmailAsSent(emailId);
}

La diferencia entre operaciones naturalmente idempotentes y las que requieren diseño es crucial. Las primeras "simplemente funcionan" en un contexto de reintentos. Las segundas necesitan que tú pienses en el caso de ejecución múltiple.

Idempotencia en Durable Functions: la regla que nadie te dice

Ahora que entiendes qué es idempotencia, conectemos con el replay model.

Cada step en una Durable Function debe ser idempotente.

¿Por qué? Porque el replay model puede re-ejecutar un step si:

La función se cae después de que el step ejecutó pero antes de que el checkpoint se guardara
Hay un error transitorio en el sistema de checkpoints
La función hace timeout justo en el momento del checkpoint

En estos casos (poco frecuentes pero reales), el step se ejecuta de nuevo con los mismos inputs. Si el step no es idempotente, tienes un problema.

El ejemplo del procesamiento de imágenes

Veamos dos versiones del step que sube la imagen procesada a S3:

// ❌ NO idempotente: genera un nombre aleatorio cada vez
const savedKey = await context.step('save-to-s3', async () => {
  const randomId = crypto.randomUUID(); // Diferente en cada ejecución
  const key = `processed/${randomId}.jpg`;

  await s3.send(new PutObjectCommand({
    Bucket: outputBucket,
    Key: key,
    Body: processedBuffer,
  }));

  return key;
});
// Si se ejecuta 2 veces: 2 archivos diferentes en S3
// processed/a1b2c3d4.jpg Y processed/e5f6g7h8.jpg

// ✅ Idempotente: usa un nombre determinístico basado en el input
const savedKey = await context.step('save-to-s3', async () => {
  const key = `processed/${baseName}-final${ext}`; // Siempre igual para el mismo input

  await s3.send(new PutObjectCommand({
    Bucket: outputBucket,
    Key: key,
    Body: processedBuffer,
  }));

  return key;
});
// Si se ejecuta 2 veces: el mismo archivo se sobrescribe
// processed/photo-final.jpg (una sola copia)

La diferencia es sutil pero crítica. En el primer caso, cada ejecución deja basura en S3. Y esa basura se acumula: archivos huérfanos que nadie usa pero que siguen sumando a tu factura de almacenamiento mes a mes. En el segundo, no importa cuántas veces se ejecute: el resultado es el mismo.

Checklist de idempotencia para tus steps

Antes de deployar, revisa cada step con estas preguntas:

[ ] ¿El step genera IDs aleatorios? → Usa IDs determinísticos basados en el input
[ ] ¿El step inserta registros en una base de datos? → Usa ConditionExpression o upsert
[ ] ¿El step envía emails o notificaciones? → Implementa deduplicación
[ ] ¿El step cobra dinero? → Usa idempotency keys del proveedor de pagos
[ ] ¿El step crea recursos en la nube? → Usa nombres determinísticos o verifica existencia antes de crear
[ ] ¿El step llama a una API externa que modifica estado? → Verifica si la API soporta idempotency keys

Si respondiste "sí" a alguna y no tienes protección, tu step no es idempotente. Y en un sistema con reintentos automáticos, eso es una bomba de tiempo.

AT_MOST_ONCE_PER_RETRY: la red de seguridad del SDK

Para operaciones críticas que no pueden ejecutarse dos veces (como cobros), el SDK ofrece una opción adicional: AT_MOST_ONCE_PER_RETRY semantics. Con esta configuración, si un step se interrumpe antes de guardar el checkpoint, el SDK no lo re-ejecuta en la siguiente invocación.

// Para operaciones que NUNCA deben duplicarse
const charge = await context.step('charge-payment', async () => {
  return chargeCard(event.amount);
}, {
  semantics: 'AT_MOST_ONCE_PER_RETRY'
});

El trade-off: si el step se interrumpe, puede que la operación se haya ejecutado pero no tengas el resultado. Tendrás que verificar manualmente (por ejemplo, consultar el sistema de pagos). Pero es mejor verificar un cobro que cobrar dos veces.

Usa AT_MOST_ONCE_PER_RETRY solo para operaciones donde la duplicación es peor que la incertidumbre. Para la mayoría de los steps, el default AT_LEAST_ONCE_PER_RETRY con diseño idempotente es la mejor opción.

Rompiendo cosas a propósito — Escenario 3: Timeout de la función

Este es el escenario más interesante. ¿Qué pasa cuando la Lambda se queda sin tiempo a mitad del workflow?

Imagina que tu función tiene un timeout de 30 segundos (el default de Lambda), pero el procesamiento completo tarda 45 segundos.

Step 1: validate-file     → 2 segundos  ✓ (checkpoint guardado)
Step 2: resize-image      → 5 segundos  ✓ (checkpoint guardado)
Step 3: apply-watermark   → 10 segundos ✓ (checkpoint guardado)
Step 4: generate-thumbnails → 15 segundos... ⏰ TIMEOUT a los 30 segundos
Step 5: save-to-s3        → nunca se ejecutó

La función se cae. Pero los primeros 3 steps tienen sus checkpoints guardados.

Cuando la función se invoca de nuevo (ya sea manualmente o por el retry automático):

Step 1: validate-file     → checkpoint existe → SKIP (0 segundos)
Step 2: resize-image      → checkpoint existe → SKIP (0 segundos)
Step 3: apply-watermark   → checkpoint existe → SKIP (0 segundos)
Step 4: generate-thumbnails → SIN checkpoint → ejecuta (15 segundos) ✓
Step 5: save-to-s3        → ejecuta (3 segundos) ✓
Total: 18 segundos → dentro del timeout ✓

El workflow completo tardó 45 segundos, pero ninguna invocación individual excedió los 30 segundos. El replay model distribuyó el trabajo entre múltiples invocaciones.

Pero espera... ¿y el `durableConfig.executionTimeout`?

Aquí hay una distinción importante:

Lambda timeout: cuánto tiempo puede correr una sola invocación de la función (máximo 15 minutos)
executionTimeout en durableConfig: cuánto tiempo puede correr el workflow completo a través de múltiples invocaciones (hasta 1 año)

// En tu CDK stack:
const imageFunction = new lambda.Function(this, 'ImageProcessing', {
  runtime: lambda.Runtime.NODEJS_24_X,
  handler: 'handler.handler',
  code: lambda.Code.fromAsset('dist'),
  timeout: cdk.Duration.minutes(5),  // Cada invocación: máximo 5 minutos
  durableConfig: {
    executionTimeout: cdk.Duration.hours(1),  // Workflow completo: máximo 1 hora
    retentionPeriod: cdk.Duration.days(7),
  },
});

Esto significa que tu workflow puede tardar hasta 1 hora en completarse, distribuido en tantas invocaciones de 5 minutos como necesite. El replay model se encarga de retomar donde quedó cada vez.

Para workflows de procesamiento de imágenes, 5 minutos por invocación suele ser suficiente. Pero para workflows que involucran aprobaciones humanas o esperas largas (que veremos en el próximo artículo), el executionTimeout de hasta 1 año es lo que hace posible esos patrones.

Monitoreando fallos en la consola

Ya rompiste cosas. Ahora necesitas ver qué pasó.

La consola de AWS Lambda tiene una pestaña dedicada para Durable Functions: Durable executions. Ahí puedes ver:

Lista de ejecuciones: todas las ejecuciones con su estado (running, completed, failed)
Detalle de cada ejecución: qué steps se completaron, cuáles fallaron, cuántos reintentos hubo
Datos de cada checkpoint: qué resultado guardó cada step
Timeline: cuánto tardó cada step y dónde ocurrieron los fallos

Tips para debugging efectivo

Nombra tus steps de forma descriptiva: 'validate-file' es mucho más útil que 'step-1' cuando estás buscando un fallo en la consola.
Usa context.logger: No uses console.log. El logger del contexto es replay-aware: no duplica logs cuando la función se reintenta. Además, incluye metadata del step actual automáticamente.

// ❌ console.log se duplica en cada replay
console.log('Processing image:', event.key);

// ✅ context.logger es replay-aware
context.logger.info('Processing image', { key: event.key });

Incluye contexto en los errores: Cuando lanzas un error, incluye datos que te ayuden a diagnosticar.

if (!metadata.format) {
  throw new Error(
    `Invalid image format. Key: ${event.key}, ` +
    `Size: ${buffer.length} bytes, ` +
    `First bytes: ${buffer.slice(0, 4).toString('hex')}`
  );
}

Revisa el estado de los checkpoints: En la consola, cada step muestra su resultado guardado. Si un step retornó datos inesperados, ahí lo vas a ver sin necesidad de reproducir el error.

Patrones de resiliencia

Antes de cerrar, un resumen de los patrones que cubrimos y algunos adicionales que deberías tener en tu toolkit:

1. Retry con backoff exponencial

Para fallos transitorios. Ya lo vimos en detalle.

await context.step('call-external-api', apiCall, {
  retryStrategy: createRetryStrategy({
    maxAttempts: 5,
    initialDelay: { seconds: 1 },
    backoffRate: 2,
    maxDelay: { seconds: 30 },
  })
});

2. Compensación

Para fallos permanentes. Ejecuta lógica de "deshacer" o "mitigar".

try {
  await context.step('charge-payment', chargeUser);
  await context.step('send-product', shipProduct);
} catch (error) {
  await context.step('refund-payment', refundUser); // Compensación
  await context.step('notify-failure', notifyUser);
}

3. Circuit breaker manual

Si un servicio externo está fallando consistentemente, no tiene sentido seguir intentando. Puedes implementar un circuit breaker básico verificando el estado del servicio antes de llamarlo.

const serviceHealth = await context.step('check-service-health', async () => {
  try {
    const response = await fetch('https://api.example.com/health');
    return response.ok;
  } catch {
    return false;
  }
});

if (!serviceHealth) {
  // El servicio está caído, no intentar
  await context.step('fallback-processing', async () => {
    context.logger.warn('External service down, using fallback');
    return processLocally(imageBuffer);
  });
} else {
  await context.step('external-processing', async () => {
    return processWithExternalService(imageBuffer);
  });
}

4. Dead letter queue para workflows irrecuperables

Cuando un workflow falla de forma definitiva y la compensación no es suficiente, envía los datos a una cola de dead letters para revisión manual.

try {
  // ... workflow completo
} catch (error) {
  await context.step('send-to-dlq', async () => {
    await sqs.send(new SendMessageCommand({
      QueueUrl: process.env.DLQ_URL,
      MessageBody: JSON.stringify({
        event,
        error: (error as Error).message,
        failedAt: new Date().toISOString(),
        executionId: context.executionId,
      }),
    }));
  });
}

Esto garantiza que ningún workflow se pierde silenciosamente. Alguien (o algo) puede revisar la cola y decidir qué hacer.

Lo que aprendiste

El replay model no es magia. Es un sistema de checkpoints que guarda el resultado de cada step y lo reutiliza cuando la función se reintenta. Los steps completados se saltan, los pendientes se ejecutan.

Los fallos transitorios se manejan con retry strategies configurables por step: exponential backoff, máximo de intentos, y topes de espera. Los fallos permanentes se manejan con try/catch y lógica de compensación: notificar, limpiar, revertir.

El código fuera de los steps se ejecuta en cada replay. Si puede fallar, debería estar dentro de un step. Si genera valores no determinísticos, definitivamente debería estar dentro de un step.

Cada step debe ser idempotente. Si se ejecuta dos veces con los mismos inputs, debe producir el mismo resultado. Para operaciones que no son naturalmente idempotentes (inserts, cobros, emails), usa idempotency keys y deduplicación.

Y la consola de AWS Lambda te da visibilidad completa: qué steps se completaron, cuáles fallaron, cuántos reintentos hubo, y qué datos se guardaron en cada checkpoint.

Rompimos cosas a propósito. Y el workflow sobrevivió.

Qué sigue

En tres artículos recorrimos el camino completo de Lambda Durable Functions: desde entender cuándo usarlas (y cuándo no), pasando por construir tu primera función con Kiro Power, hasta romper cosas a propósito para entender cómo el replay model mantiene tu progreso.

Si llegaste hasta aquí, ya tienes las herramientas para construir workflows resilientes en producción. Sabes cómo funcionan los checkpoints, cómo configurar retries con backoff exponencial, cómo manejar fallos permanentes con compensación, y por qué la idempotencia no es opcional.

Durable Functions tiene más por explorar: callbacks para aprobaciones humanas, waits que pausan ejecución sin costo, ejecución en paralelo con context.map(), e invocaciones entre funciones con context.invoke(). La documentación oficial y el SDK de Durable Execution cubren todo eso en detalle.

Construye. Rompe. Recupera. Esa es la promesa.

Si quieres profundizar en Durable Functions, estos recursos te llevan más lejos:

Documentación oficial de Lambda Durable Functions — El punto de partida para todo: callbacks, waits, ejecución en paralelo, y más
Best practices for Lambda durable functions — Determinismo, idempotencia, manejo de estado, y errores comunes
Durable Execution SDK — Retry Strategies — Referencia completa de createRetryStrategy, presets, y custom strategies
Durable Execution SDK (JavaScript) — Código fuente del SDK, open source
Proyecto de ejemplo de esta serie (GitHub) — El código completo del procesamiento de imágenes

Cómo crear un agente de IA desde cero. Open source, local y gratis.

Hazel Saenz — Wed, 15 Apr 2026 16:15:25 +0000

De un modelo que solo responde a uno que busca, razona y recuerda con código que puedes leer, forkear y contribuir.

Todos hemos usado ChatGPT, Claude, Google Gemini. Les preguntas algo, te responden. Les pides que resuman un texto, lo resumen. Les dices que escriban un correo, lo escriben. Pero hay un límite. Un modelo de lenguaje puede hablar de música. Puede hablar de géneros. Puede hablar de artistas.

Pero no puede buscar en tu biblioteca de canciones.
No puede analizar el mood de una playlist.
No puede recordar que la semana pasada te armó una playlist de hip-hop para el gym y te encantó.

Un modelo solo habla.
Un agente hace cosas.

Y esa diferencia es más importante de lo que parece.

¿Qué es un agente de IA?

Si ya usaste la API de OpenAI o jugaste con modelos en Hugging Face, sabes que un LLM recibe texto y genera texto. Punto. No ejecuta código, no consulta bases de datos, no llama APIs.

Un agente agrega dos cosas encima de eso:

Herramientas (tools): funciones que el modelo puede invocar cualquier función de Python que le expongas
Un agent loop: un ciclo donde el modelo razona, decide si necesita llamar una herramienta, la ejecuta, recibe el resultado, y vuelve a razonar hasta tener una respuesta final

No es magia. Es un while loop con tool dispatch.

Imagina que le preguntas a un agente DJ: "Armame una playlist para una cena tranquila con amigos."

Sin tools, el modelo genera texto basado en su entrenamiento, no conoce tu biblioteca, no sabe qué se lanzó la semana pasada (su conocimiento tiene fecha de corte), y no tiene idea de tus gustos. Con tools, hace esto:

Razona: "Necesito buscar canciones con energía baja"
Invoca: buscar_canciones(mood="chill", genero="jazz")
Recibe el resultado: una lista de canciones reales de tu biblioteca
Razona de nuevo: "Debería verificar que la energía sea consistente"
Invoca: analizar_energia(canciones=[...])
Genera la respuesta final: una playlist curada con datos reales

El modelo decide qué herramientas invocar y en qué orden. Tú no escribes la orquestación, el modelo la resuelve en runtime. Eso es el enfoque model-driven, y es lo que diferencia a un agente de un pipeline hardcodeado con if/else.

Por qué open source importa (de verdad)

Cuando hablamos de agentes de IA, hay muchas opciones. Frameworks propietarios, APIs cerradas, SDKs que solo funcionan con un proveedor específico.

El problema no es que existan. El problema es lo que pierdes cuando los usas:

No puedes leer la implementación del agent loop, si el modelo toma una secuencia de tool calls inesperada, no puedes entender por qué ni cambiar el comportamiento
No puedes modificar el comportamiento del loop cuando algo no funciona como esperas
Si tu proveedor de modelo no está soportado, no puedes contribuir la integración tú mismo ni aprovechar una que la comunidad ya haya creado
No puedes contribuir fixes o mejoras que beneficien a otros

Open source no es solo "código gratis". Sí, requiere más responsabilidad de tu parte: tú debuggeas, tú actualizas, tú decides. Pero esa responsabilidad viene con control total. Es transparencia. Es poder abrir el source del agent loop y ver que es un while loop con tool dispatch. Es poder poner un breakpoint en el ciclo de razonamiento cuando tu agente hace algo inesperado.

Y eso es exactamente lo que vamos a usar.

El stack: Python + Strands Agents + Ollama

Todo lo que vas a ver en este artículo corre con tres cosas:

Python: el lenguaje (licencia PSF, open source)
Strands Agents: un SDK open source (licencia Apache 2.0) para construir agentes de IA
Ollama: un runtime open source (licencia MIT) para correr modelos de lenguaje localmente

Todo open source. Todo en tu laptop. Sin API keys. Sin vendor lock-in. Sin datos saliendo de tu máquina.

Strands Agents toma un enfoque model-driven: tú defines las herramientas como funciones de Python, escribes un system prompt, y el agent loop se encarga de la ejecución. Sin definiciones de pasos, sin grafos de workflow. Solo código.

Ollama: modelos de IA en tu laptop

Antes de construir el agente, necesitamos un modelo de lenguaje corriendo localmente. Y aquí es donde entra Ollama.

Ollama es un runtime open source para correr LLMs en tu máquina. Si conoces Docker, la analogía es directa: ollama pull descarga un modelo, ollama serve lo expone como API REST en localhost:11434. Sin cuentas, sin API keys, sin datos saliendo de tu red.

Instalación

En macOS y Linux:

curl -fsSL https://ollama.com/install.sh | sh

En Windows, descarga el instalador desde ollama.com/download.

Descargar y correr un modelo

Para este artículo vamos a usar llama3.1:8b — tiene buen soporte para tool-calling (que es lo que necesitamos para que el agente invoque funciones) y maneja español razonablemente bien:

ollama pull llama3.1

Son unos 4.9 GB. Solo necesitas hacerlo una vez.

Ahora levanta el servidor:

ollama serve

Nota: Si instalaste la app de macOS, el servidor ya está corriendo en segundo plano y no necesitas ejecutar ollama serve. Solo es necesario si instalaste con Homebrew o en Linux.

Ollama queda escuchando en http://localhost:11434. Puedes verificar con un curl http://localhost:11434/api/tags para ver los modelos disponibles.

Ollama soporta muchos modelos: Llama, Mistral, Phi, Gemma, y más. Si tu máquina tiene GPU, los corre acelerados automáticamente. Si no, usa CPU (más lento, pero funciona).

Lo importante: el modelo corre en tu máquina. Tus datos no salen de tu laptop. Y el código de Ollama es open source.

Capa 1: Un agente que solo habla

Empecemos por lo más simple. Un agente que es solo un modelo + un prompt.

Primero, instala el SDK de Strands con soporte para Ollama.

Nota: Strands Agents requiere Python 3.10 o superior. El Python que viene preinstalado en macOS (3.9.6) no es compatible. Si no tienes una versión reciente, instálala con brew install python@3.13.

Crea un entorno virtual para no contaminar tu sistema. Con pip:

python3 -m venv .venv
source .venv/bin/activate
pip install 'strands-agents[ollama]'

O si usas uv (más rápido y gestiona Python por ti):

uv venv --python 3.13
source .venv/bin/activate
uv pip install 'strands-agents[ollama]'

Ahora, el código:

from strands import Agent
from strands.models.ollama import OllamaModel

modelo = OllamaModel(
    model_id="llama3.1",
    host="http://localhost:11434",
)

dj = Agent(
    model=modelo,
    system_prompt="""Eres un DJ y curador musical experto.
    Respondes en español, con onda y buen gusto.
    Recomiendas música basándote en el mood, la ocasión, y los gustos del usuario."""
)

dj("Recomiéndame algo para escuchar mientras programo")

Cinco líneas relevantes. Eso es un agente.

Bueno, técnicamente es un modelo con un prompt — todavía no tiene herramientas, así que solo responde con su conocimiento general. Si le pides una playlist con canciones de tu biblioteca, va a alucinar títulos que suenan razonables pero no existen.

Un agente es un modelo + un prompt + un loop. Eso es todo.

Y fíjate: el modelo corre local. No hay API key, no hay vendor, no hay datos saliendo de tu laptop.

Capa 2: Dale herramientas — la biblioteca de canciones

El agente básico no conoce tu música. Sabe de artistas y géneros en general porque fue entrenado con texto de internet. Pero no sabe que en tu biblioteca tienes ese álbum de la Ley que siempre pones cuando cocinas.

Para eso necesita una herramienta.

Pero primero, necesitamos datos. Crea un archivo data/canciones.json con tu biblioteca de canciones. Cada canción necesita: titulo, artista, genero, mood, energia (0-100), y duracion_min. Aquí tienes un ejemplo para arrancar:

Ver ejemplo de data/canciones.json (30 canciones)

[
  {"titulo": "So What", "artista": "Miles Davis", "genero": "jazz", "mood": "chill", "energia": 30, "duracion_min": 9.3},
  {"titulo": "Take Five", "artista": "Dave Brubeck", "genero": "jazz", "mood": "chill", "energia": 35, "duracion_min": 5.4},
  {"titulo": "Blue in Green", "artista": "Miles Davis", "genero": "jazz", "mood": "melancólico", "energia": 20, "duracion_min": 5.4},
  {"titulo": "Fly Me to the Moon", "artista": "Frank Sinatra", "genero": "jazz", "mood": "chill", "energia": 40, "duracion_min": 3.5},
  {"titulo": "Feeling Good", "artista": "Nina Simone", "genero": "jazz", "mood": "energético", "energia": 55, "duracion_min": 2.9},
  {"titulo": "Bohemian Rhapsody", "artista": "Queen", "genero": "rock", "mood": "energético", "energia": 80, "duracion_min": 5.9},
  {"titulo": "Hotel California", "artista": "Eagles", "genero": "rock", "mood": "chill", "energia": 45, "duracion_min": 6.5},
  {"titulo": "Smells Like Teen Spirit", "artista": "Nirvana", "genero": "rock", "mood": "energético", "energia": 90, "duracion_min": 5.0},
  {"titulo": "Under Pressure", "artista": "Queen &amp; David Bowie", "genero": "rock", "mood": "energético", "energia": 75, "duracion_min": 4.0},
  {"titulo": "Creep", "artista": "Radiohead", "genero": "rock", "mood": "melancólico", "energia": 50, "duracion_min": 3.9},
  {"titulo": "Gasolina", "artista": "Daddy Yankee", "genero": "reggaetón", "mood": "fiesta", "energia": 95, "duracion_min": 3.1},
  {"titulo": "Dákiti", "artista": "Bad Bunny &amp; Jhay Cortez", "genero": "reggaetón", "mood": "fiesta", "energia": 80, "duracion_min": 3.3},
  {"titulo": "Tití Me Preguntó", "artista": "Bad Bunny", "genero": "reggaetón", "mood": "fiesta", "energia": 85, "duracion_min": 4.0},
  {"titulo": "Pepas", "artista": "Farruko", "genero": "reggaetón", "mood": "fiesta", "energia": 92, "duracion_min": 4.5},
  {"titulo": "La Bicicleta", "artista": "Shakira &amp; Carlos Vives", "genero": "reggaetón", "mood": "fiesta", "energia": 78, "duracion_min": 3.8},
  {"titulo": "Midnight City", "artista": "M83", "genero": "electrónica", "mood": "energético", "energia": 75, "duracion_min": 4.0},
  {"titulo": "Strobe", "artista": "Deadmau5", "genero": "electrónica", "mood": "chill", "energia": 55, "duracion_min": 10.3},
  {"titulo": "Around the World", "artista": "Daft Punk", "genero": "electrónica", "mood": "fiesta", "energia": 82, "duracion_min": 7.1},
  {"titulo": "Intro", "artista": "The xx", "genero": "electrónica", "mood": "chill", "energia": 25, "duracion_min": 2.1},
  {"titulo": "Teardrop", "artista": "Massive Attack", "genero": "electrónica", "mood": "melancólico", "energia": 35, "duracion_min": 5.3},
  {"titulo": "Disorder", "artista": "Joy Division", "genero": "indie", "mood": "melancólico", "energia": 60, "duracion_min": 3.6},
  {"titulo": "Do I Wanna Know?", "artista": "Arctic Monkeys", "genero": "indie", "mood": "chill", "energia": 55, "duracion_min": 4.6},
  {"titulo": "Somebody Else", "artista": "The 1975", "genero": "indie", "mood": "melancólico", "energia": 45, "duracion_min": 5.7},
  {"titulo": "Electric Feel", "artista": "MGMT", "genero": "indie", "mood": "energético", "energia": 72, "duracion_min": 3.8},
  {"titulo": "Tongue", "artista": "MNEK", "genero": "indie", "mood": "energético", "energia": 68, "duracion_min": 3.5},
  {"titulo": "Only Shallow", "artista": "My Bloody Valentine", "genero": "shoegaze", "mood": "energético", "energia": 70, "duracion_min": 4.2},
  {"titulo": "When You Sleep", "artista": "My Bloody Valentine", "genero": "shoegaze", "mood": "chill", "energia": 45, "duracion_min": 4.1},
  {"titulo": "Alison", "artista": "Slowdive", "genero": "shoegaze", "mood": "melancólico", "energia": 40, "duracion_min": 5.1},
  {"titulo": "Cherry-coloured Funk", "artista": "Cocteau Twins", "genero": "shoegaze", "mood": "chill", "energia": 38, "duracion_min": 4.5},
  {"titulo": "Vapour Trail", "artista": "Ride", "genero": "shoegaze", "mood": "energético", "energia": 65, "duracion_min": 4.2}
]

Puedes modificar este archivo con tu propia música. Lo importante es que mantenga la misma estructura.

Ahora sí, en Strands, crear una herramienta es decorar una función de Python:

from strands import Agent, tool
from strands.models.ollama import OllamaModel
import json

# Cargar biblioteca local de canciones
with open("data/canciones.json") as f:
    BIBLIOTECA = json.load(f)

@tool
def buscar_canciones(genero: str = "", mood: str = "", artista: str = "") -> str:
    """Busca canciones en la biblioteca musical del usuario.

    Args:
        genero: Género musical (ej: rock, jazz, reggaetón, electrónica)
        mood: Estado de ánimo o energía (ej: chill, fiesta, melancólico, energético)
        artista: Nombre del artista o banda
    """
    resultados = BIBLIOTECA
    if genero:
        resultados = [c for c in resultados if genero.lower() in c["genero"].lower()]
    if mood:
        resultados = [c for c in resultados if mood.lower() in c["mood"].lower()]
    if artista:
        resultados = [c for c in resultados if artista.lower() in c["artista"].lower()]

    if not resultados:
        return "No encontré canciones con esos criterios en tu biblioteca."

    return json.dumps(resultados[:10], ensure_ascii=False, indent=2)

Fíjate en el decorador @tool. Convierte cualquier función de Python en una herramienta que el agente puede invocar. El docstring no es decorativo — el SDK lo parsea para generar un tool spec (JSON schema) que es lo que el modelo recibe para decidir cuándo y cómo usar la herramienta. Si el docstring es vago, el modelo no va a saber cuándo llamarla.

Ahora conectamos la herramienta al agente:

modelo = OllamaModel(model_id="llama3.1", host="http://localhost:11434")

dj = Agent(
    model=modelo,
    system_prompt="""Eres un DJ y curador musical experto.
    Usa la herramienta buscar_canciones para encontrar música en la biblioteca del usuario.
    Siempre basa tus recomendaciones en canciones que el usuario realmente tiene.""",
    tools=[buscar_canciones]
)

dj("Quiero escuchar jazz mientras trabajo")

Ahora cuando le pides jazz para trabajar, el agente no inventa. Llama a buscar_canciones(genero="jazz", mood="chill"), obtiene canciones reales de tu biblioteca, y arma una recomendación con lo que realmente tienes.

Pasó de "saber cosas" a "hacer cosas".

Y el sistema de tools es extensible. Existe un paquete de community tools donde cualquiera puede publicar los suyos. ¿Tienes una API que quieres conectar? Escribe un @tool y compártelo.

Capa 3: Más herramientas, más inteligencia

Un tool está bien. Pero la cosa se pone interesante cuando agregas varios.

@tool
def analizar_energia(canciones: list) -> str:
    """Analiza el nivel de energía promedio de una lista de canciones y sugiere el orden ideal.

    Args:
        canciones: Lista de nombres de canciones a analizar
    """
    energia_map = {}
    for cancion in BIBLIOTECA:
        energia_map[cancion["titulo"].lower()] = cancion.get("energia", 50)

    analisis = []
    for titulo in canciones:
        energia = energia_map.get(titulo.lower(), 50)
        analisis.append({"titulo": titulo, "energia": energia})

    # Ordenar por energía para un flow natural
    analisis.sort(key=lambda x: x["energia"])
    promedio = sum(c["energia"] for c in analisis) / len(analisis) if analisis else 0

    return json.dumps({
        "energia_promedio": round(promedio),
        "flow": "ascendente" if analisis[0]["energia"] < analisis[-1]["energia"] else "descendente",
        "orden_sugerido": [c["titulo"] for c in analisis],
        "nota": "Energía baja → alta para ir subiendo el mood" if promedio < 60 else "Playlist con buena energía"
    }, ensure_ascii=False)

@tool
def duracion_playlist(canciones: list) -> str:
    """Calcula la duración total de una playlist y sugiere si necesita más canciones.

    Args:
        canciones: Lista de nombres de canciones
    """
    duracion_map = {}
    for cancion in BIBLIOTECA:
        duracion_map[cancion["titulo"].lower()] = cancion.get("duracion_min", 3.5)

    total = sum(duracion_map.get(t.lower(), 3.5) for t in canciones)

    return json.dumps({
        "canciones": len(canciones),
        "duracion_total_min": round(total, 1),
        "duracion_formato": f"{int(total // 60)}h {int(total % 60)}min" if total >= 60 else f"{int(total)}min",
        "sugerencia": "Playlist corta, podrías agregar más canciones" if total < 30 else "Buena duración"
    }, ensure_ascii=False)

Ahora el agente tiene tres herramientas. Y aquí es donde se ve el agent loop en acción:

dj = Agent(
    model=modelo,
    system_prompt="""Eres un DJ y curador musical experto.
    Usa tus herramientas para armar playlists basadas en la biblioteca real del usuario.
    Considera el mood, la energía, y la duración para crear una experiencia coherente.""",
    tools=[buscar_canciones, analizar_energia, duracion_playlist]
)

dj("Armame una playlist de una hora para una fiesta en casa")

El agente no ejecuta las herramientas en un orden predefinido. No hay un pipeline que diga "primero busca, luego analiza, luego calcula duración". El modelo recibe los tool specs (nombre, descripción, parámetros) y en cada iteración del loop decide: ¿necesito más información? ¿Qué tool me la da? ¿Con qué parámetros?

En este caso: llama a buscar_canciones(mood="fiesta"), analiza la energía con analizar_energia(canciones=[...]) para ordenarlas con un flow ascendente, y verifica la duración con duracion_playlist(canciones=[...]) para cubrir la hora completa. Si la duración no alcanza, puede volver a llamar buscar_canciones con otros criterios.

Tú no orquestaste nada. El modelo resolvió la secuencia en runtime.

Nota sobre modelos locales: con llama3.1:8b, el agente invoca los tools correctamente pero a veces ignora los resultados y alucina canciones que no están en tu biblioteca. Esto es una limitación del tamaño del modelo (8B parámetros), no del SDK. Con una sola herramienta (Capa 2) funciona bien; con múltiples tools el modelo se confunde más fácilmente. Si necesitas tool-calling más confiable, usa un modelo más grande (llama3.1:70b) o un modelo cloud como Claude o GPT-4 (ver la sección "De tu laptop a la nube").

Y si quieres entender cómo funciona por dentro, el código está ahí. El agent loop de Strands no es una caja negra. Es código abierto que puedes leer en GitHub.

Capa 4: Memoria — el DJ te conoce

Hay un problema con todo lo que hemos construido hasta ahora.

Cada conversación empieza de cero.

Le dices "me encanta el indie rock", cierras la conversación, vuelves al día siguiente, y el agente no tiene idea de quién eres. Es como ir a un bar donde el DJ cambia cada vez que parpadeas.

Strands resuelve esto con session management. FileSessionManager persiste el historial de conversación a disco como archivos JSON, organizados por sesión y agente. Cuando el agente se inicializa con un session_id existente, carga los mensajes anteriores y el modelo los tiene como contexto.

from strands import Agent
from strands.models.ollama import OllamaModel
from strands.session.file_session_manager import FileSessionManager

modelo = OllamaModel(model_id="llama3.1", host="http://localhost:11434")

# El session manager guarda las conversaciones a disco
# session_id identifica al usuario, storage_dir es donde se guardan los archivos
session_manager = FileSessionManager(session_id="usuario-1", storage_dir="./sesiones")

dj = Agent(
    model=modelo,
    system_prompt="""Eres un DJ y curador musical experto.
    Recuerdas los gustos del usuario entre conversaciones.
    Si el usuario ya te dijo qué le gusta, úsalo para personalizar tus playlists.""",
    tools=[buscar_canciones, analizar_energia, duracion_playlist],
    session_manager=session_manager,
)

# Primera conversación
dj("Me encanta el indie rock y el shoegaze. No soporto el reggaetón.")

# ... tiempo después, otra conversación ...

# El agente recuerda
dj("Armame algo para el viernes")
# → Arma una playlist de indie rock y shoegaze, sin reggaetón

Pocas líneas y tu agente tiene continuidad.

Y aquí viene lo interesante desde el punto de vista open source: FileSessionManager es una implementación de la interfaz SessionManager. Guarda sesiones a disco como archivos JSON organizados por sesión y agente. Pero si quieres guardar sesiones en Redis, en Postgres, o en S3, implementas la interfaz y listo. Ya existen session managers de la comunidad, como el de AgentCore Memory. La arquitectura está diseñada para que la comunidad la extienda.

De tu laptop a la nube (en una línea)

Todo lo que hemos construido corre localmente. Ollama en tu máquina, modelo en tu máquina, datos en tu máquina.

Pero si quieres compartir tu agente con el mundo, necesitas algo más.

Y aquí está lo elegante de la arquitectura: el SDK abstrae el model provider detrás de una interfaz común. Cambiar de proveedor es cambiar la instanciación del modelo — el resto del código no se entera.

# Local con Ollama
from strands.models.ollama import OllamaModel
modelo = OllamaModel(model_id="llama3.1", host="http://localhost:11434")

# En la nube con Amazon Bedrock
from strands.models import BedrockModel
modelo = BedrockModel(model_id="us.anthropic.claude-sonnet-4-20250514-v1:0", region_name="us-east-1")

El resto del código del agente no cambia. Ni una línea. Los tools, el system prompt, el session manager: todo igual. Esto es posible porque Strands define una interfaz Model que todos los providers implementan — OllamaModel, BedrockModel, OpenAIModel, AnthropicModel, etc.

Esa es la arquitectura en capas:

La capa open source es la constante. El proveedor de abajo es la variable. Ollama, Bedrock, OpenAI, Anthropic, Google Gemini, LiteLLM: todos son plugins que implementan la misma interfaz. Sin esa capa de abstracción, estás atado al SDK del vendor con el que empezaste.

Lo que aprendiste

Un agente de IA no es magia. Es un modelo + herramientas + un loop de razonamiento.

Construimos un DJ de playlists capa por capa: primero un agente que solo habla, luego le dimos herramientas para buscar en una biblioteca real de canciones, después agregamos más tools y vimos cómo el modelo decide solo qué llamar y en qué orden, le dimos memoria para que recuerde tus gustos, y al final mostramos que el mismo código puede correr local o en la nube cambiando una línea.

Todo con Python, Strands Agents y Ollama. Todo open source. Todo en tu laptop.

Qué sigue

Si quieres ir más allá:

Documentación de Strands Agents — guías, ejemplos, y API reference
Repo de Strands en GitHub — el código fuente completo, licencia Apache 2.0
Community tools — herramientas creadas por la comunidad que puedes usar y extender
Ollama — para correr modelos localmente

El DJ sabe de música. ¿Qué vas a construir tú?

¿Te resultó útil este artículo? Compártelo con tu equipo o déjame saber en los comentarios qué agente te gustaría construir. Y si ya estás experimentando con Strands o con agentes de IA en general, me encantaría escuchar tu experiencia.

Escala Inteligente con Microservicios Serverless

Hazel Saenz — Tue, 24 Mar 2026 17:57:16 +0000

Cuándo dividir, cómo conectar y qué patrones usar para no crear un monolito distribuido.

Hace un tiempo me tocó trabajar en un proyecto donde todo funcionaba. Un monolito. Un deploy, un repo, un equipo. Respondía rápido, los usuarios estaban contentos, el jefe estaba contento.

Hasta que alguien en una conferencia dijo: "los microservicios son el futuro".

Y miramos nuestro monolito y pensamos: "esto no escala, necesitamos microservicios".

Tres meses después teníamos 15 servicios. Un request del usuario pasaba por 7 de ellos antes de responder. Si inventario iba lento, el checkout se caía. Si notificaciones fallaba, nadie sabía por qué el pedido se quedó a medias.

Teníamos un monolito distribuido. Los mismos problemas de antes, pero ahora con latencia de red y 12 dashboards que nadie entendía.

La complejidad no desapareció. Solo cambió de forma.

Si alguna vez sentiste que migrar a microservicios iba a resolver todos tus problemas y terminó creando nuevos... este artículo es para ti.

¿Realmente necesitas microservicios?

Antes de hablar de cómo, hablemos de cuándo. Porque la decisión más inteligente a veces es no dividir.

Cuando empecé a investigar más sobre el tema, me di cuenta de que muchas migraciones a microservicios no nacen de un problema real. Nacen del hype. De escuchar que "Netflix usa microservicios" y asumir que nosotros también deberíamos.

Pero Netflix llegó a microservicios después de años de crecimiento y con miles de ingenieros dedicados a esa transición. El contexto importa: lo que funciona para una empresa con esa escala no necesariamente aplica para todos los equipos.

Señales reales vs. falsas alarmas

✅ Señales reales para dividir	❌ Falsas alarmas
Equipos se bloquean entre sí para hacer deploy	"Netflix usa microservicios"
Un componente necesita escalar 100x más que el resto	"Mi monolito es legacy"
Dominios de negocio claramente independientes	"Quiero usar tecnologías diferentes por servicio"
Ciclos de release muy diferentes entre componentes	"Los microservicios son más modernos"
Un fallo en un módulo tumba todo el sistema	"Mi equipo de 3 personas necesita agilidad"

Si tu equipo es pequeño y todo cabe en un deploy, no necesitas microservicios. Necesitas un monolito bien estructurado.

Divide cuando el dolor es real: equipos que se bloquean, componentes que necesitan escalar de forma radicalmente diferente, dominios de negocio que evolucionan a ritmos distintos.

No dividas porque suena moderno.

No es binario — hay un espectro

Algo que me costó entender al principio es que no es "monolito o microservicios". Hay un espectro completo entre ambos:

La mayoría de los sistemas no necesitan ir directo a microservicios.

Empieza con un monolito modular: un solo deploy, pero con límites claros entre dominios. Cuando un módulo necesite escalar o evolucionar independientemente, lo extraes.

Eso es escalar inteligente: dividir cuando hay evidencia, no cuando hay hype.

Serverless cambia las reglas

Cuando trabajas con microservicios tradicionales, cada servicio necesita su servidor, su scaling, su service discovery. Es mucha carga operativa.

Serverless cambia eso por completo:

Microservicios Tradicionales	Microservicios Serverless
Tú manejas servidores por servicio	Sin servidores que gestionar
Tú configuras auto-scaling	Escala automática por función
Pagas por servidor encendido	Pagas por ejecución
Tú manejas service discovery	Eventos y colas conectan servicios
Kubernetes, Docker, load balancers	Lambda, API Gateway, EventBridge

Pero hay algo que quiero dejar claro porque es una confusión muy común:

Un microservicio serverless no es UNA Lambda.

Es la colección de Lambdas detrás de un API Gateway que resuelven un dominio de negocio. Pedidos, inventario, pagos, cada uno es un microservicio compuesto por varias funciones pequeñas y enfocadas.

Si metes toda la lógica en una sola Lambda gigante, estás creando un monolito dentro de una función.

La pregunta ya no es "cómo escalo este servicio" sino "cómo conecto estos servicios de forma inteligente".

Y ahí es donde entran los patrones.

Los 3 patrones clave

Después de haber pasado por varias migraciones (algunas exitosas, otras no tanto), identifiqué tres patrones que marcan la diferencia entre una arquitectura de microservicios que funciona y un monolito distribuido disfrazado.

Los presento aquí a nivel conceptual. Cada uno tendrá su artículo dedicado con implementación práctica y código real.

Patrón 1: Comunicación desacoplada — eventos, no llamadas directas

Este fue el error que más me costó entender.

Cuando empezamos a dividir servicios, lo primero que hicimos fue conectar Lambdas en cadena. Lambda A llama a B, B llama a C. Parecía lógico.

El problema:

Si C falla, todo falla. Las latencias se suman. Estás recreando el monolito pero con más latencia.

El patrón correcto es usar eventos asíncronos:

Tu microservicio responde al usuario y emite un evento. Los demás microservicios reaccionan al evento a su propio ritmo.

Desacoplados. Independientes. Resilientes.

Amazon EventBridge actúa como un bus de eventos serverless que desacopla la lógica de enrutamiento de tus microservicios. Amazon SQS te da colas de mensajes para procesamiento asíncrono con garantías de entrega. Ambos son piezas fundamentales para este patrón.

En el próximo artículo de la serie vamos a implementar este patrón paso a paso con EventBridge y SQS, incluyendo las trampas que te puedes encontrar.

Patrón 2: Cada servicio, su data

Este es directo y no tiene vuelta:

Si todos tus servicios leen y escriben en la misma tabla de DynamoDB, no tienes microservicios. Tienes un monolito disfrazado.

El patrón correcto:

Cada servicio es dueño de su data. Si otro servicio necesita esa información, la pide por evento o por API.

Nunca por query directo a la base de datos ajena.

¿Por qué? Porque si compartes la base de datos, cualquier cambio de schema puede romper múltiples servicios al mismo tiempo. Y ahí se fue tu independencia.

Esto se conoce como database per service y suena simple, pero tiene implicaciones importantes, como qué pasa cuando una transacción involucra múltiples servicios (spoiler: necesitas el patrón Saga).

En el tercer artículo de la serie vamos a profundizar en este patrón y en cómo manejar transacciones distribuidas con Sagas.

Patrón 3: Observabilidad desde el día 1

En un monolito, un error aparece en un log. En microservicios, un error puede estar en cualquiera de 10 servicios.

Sin observabilidad, estás debuggeando a ciegas. Y te lo digo por experiencia: no hay nada más frustrante que saber que algo falló y no poder encontrar dónde.

Los tres pilares que necesitas desde el día 1:

1. Logs estructurados con correlation ID

Nota importante: Cada request que entra a tu sistema debe llevar un ID único que viaje por todos los servicios. Cuando algo falla, buscas ese ID y ves el camino completo.

Lambda Powertools te lo da casi gratis, inyecta correlation IDs, estructura tus logs en JSON y agrega contexto automáticamente.

2. Traces distribuidos

AWS X-Ray y AWS Distro for OpenTelemetry (ADOT) te permiten ver el viaje completo de cada request a través de todos los servicios. Puedes identificar exactamente dónde está el bottleneck.

Nota importante: AWS está convergiendo hacia OpenTelemetry como estándar de instrumentación. ADOT te da una distribución optimizada para AWS que envía traces y métricas a X-Ray, CloudWatch y otros destinos.

3. Métricas de negocio

No solo "cuántos errores 500" sino "cuántos pedidos se perdieron por minuto". Las métricas técnicas te dicen que algo falló. Las métricas de negocio te dicen cuánto te costó.

Si no puedes ver qué pasa, no puedes arreglar lo que falla. En el cuarto artículo de la serie vamos a implementar observabilidad completa con Lambda Powertools, X-Ray y métricas custom.

El framework de decisión

Después de todo lo que vimos, quiero dejarte algo práctico. Un framework que puedes usar la próxima vez que alguien diga "necesitamos microservicios":

No empieces por la tecnología. Empieza por las preguntas.

Si la respuesta a todo es no, quédate con tu monolito. Si es sí, extrae con estrategia.

Lo que quiero que te lleves

🧠 Decide con evidencia, no con hype: Microservicios no son el default. Son una herramienta para problemas específicos.
📐 Empieza modular, extrae después: Monolito modular → macro-servicios → microservicios. En ese orden.
🔌 Eventos sobre llamadas directas: Desacopla con EventBridge/SQS. Nunca encadenes Lambdas síncronamente.
🗄️ Cada servicio, su data: Base de datos compartida = monolito disfrazado.
👀 Observabilidad no es opcional: Correlation IDs, X-Ray/OpenTelemetry, métricas de negocio. Desde el día 1.

Qué sigue

Este artículo es el mapa conceptual. Los siguientes artículos de la serie van a profundizar en cada patrón con implementación práctica y código real:

Comunicación desacoplada con EventBridge y SQS: Implementación paso a paso, trampas comunes y demo funcional
Database per service y el patrón Saga: Cómo manejar transacciones distribuidas con acciones compensatorias
Observabilidad en microservicios serverless: Lambda Powertools, X-Ray/OpenTelemetry y métricas de negocio en acción

"Escalar inteligente no es tener más servicios. Es tomar mejores decisiones."

Recursos

Si quieres profundizar más, estos son los recursos oficiales de AWS que recomiendo:

Implementing Microservices on AWS — Whitepaper completo sobre patrones API-driven, event-driven y data streaming
Microservices on Serverless Technologies — Arquitecturas serverless con Lambda, API Gateway y Fargate
Integrating Microservices by Using AWS Serverless Services — Guía prescriptiva sobre comunicación síncrona y asíncrona entre microservicios
Cloud Design Patterns, Architectures, and Implementations — Patrones como Saga, circuit breaker, event sourcing y strangler fig aplicados con servicios AWS

¿Te resultó útil este artículo? Compártelo con tu equipo. Y si ya pasaste por una migración a microservicios exitosa o no me encantaría escuchar tu experiencia.

AWS Lambda Durable Functions + IA: el combo que no sabías que necesitabas

Hazel Saenz — Wed, 18 Mar 2026 16:56:38 +0000

Cómo instalar y usar el nuevo Kiro Power para Lambda Durable Functions paso a paso.

En el artículo anterior vimos que Lambda Durable Functions y Step Functions no compiten. Son dos filosofías diferentes para resolver el mismo problema: orquestación de workflows.

Step Functions orquesta visualmente. Durable Functions orquesta en código.

Y prometí que en este artículo íbamos a pasar de la teoría a la práctica.

Pero hay un detalle que no mencioné:

👉 Construir tu primera Durable Function no tiene que ser complicado.

Porque desde marzo de 2026, existe un Kiro Power que te guía paso a paso. Con IA. Dentro de tu IDE.

Y eso cambia todo.

Espera... ¿qué es Kiro?

Si es la primera vez que escuchas el nombre, no te preocupes.

Kiro es un IDE creado por AWS, potenciado con IA. Piensa en él como tu editor de código, pero con un agente de IA integrado que entiende lo que estás construyendo y te ayuda a hacerlo mejor.

No es un chatbot que pega código de internet. No es un autocompletado glorificado.

Es un agente que entiende el contexto de tu proyecto, sigue buenas prácticas, y te guía mientras escribes código.

Puedes usarlo para escribir código, debuggear, hacer deploy, y mucho más. Si quieres conocerlo a fondo, te recomiendo esta guía de primeros pasos con Kiro. Pero lo que lo hace especial para este artículo es algo llamado Powers.

¿Qué es un Kiro Power?

Un Power es como darle superpoderes especializados al agente de IA de Kiro.

Sin un Power, el agente sabe de todo un poco. Con un Power instalado, el agente se convierte en experto en un tema específico.

Piensa en esto: si le pides a un asistente genérico que te ayude a construir una Durable Function, probablemente te dé una respuesta genérica. Puede que funcione. Puede que no.

Pero si ese asistente tiene cargado un Power de Lambda Durable Functions, se convierte en un experto que sabe las reglas, los patrones, y las trampas comunes. Y carga esa información dinámicamente según lo que estés haciendo.

El Lambda Durable Functions Power

El 5 de marzo de 2026, AWS lanzó el Kiro Power para Lambda Durable Functions.

Incluye guía especializada para todo el ciclo de desarrollo: desde el setup del proyecto y las reglas del replay model, pasando por steps, waits, callbacks, ejecución en paralelo, manejo de errores, testing local, hasta deploy con CDK, SAM, o CloudFormation.

No tienes que leer toda la documentación antes de empezar. El Power te da lo que necesitas, cuando lo necesitas.

Instalando el Power

Esto es la parte más fácil. Literalmente un clic.

Abre Kiro
Ve al panel de Powers (en la barra lateral)
En la sección Available, busca "Lambda Durable Functions"
Haz clic en Install

Eso es todo.

No hay configuración adicional. No hay dependencias que instalar manualmente para el Power. Una vez instalado, el agente de Kiro ya tiene acceso a toda la guía especializada.

Nota: No todos los servicios de AWS tienen un Power dedicado. Los Powers son módulos especializados que se van agregando con el tiempo. Puedes explorar los disponibles en el panel de Powers de Kiro.

Ahora sí, vamos a construir algo.

Prerequisitos

Antes de escribir código, necesitas tener algunas herramientas instaladas. Los siguientes comandos te ayudan a verificar si ya las tienes. Si alguno falla, sigue el link de documentación correspondiente para instalarlo.

AWS CLI instalado (versión 2.33.22 o superior) y configurado con tus credenciales:

aws --version
aws sts get-caller-identity

Node.js 22+ instalado (para este tutorial usaremos TypeScript):

node --version

AWS CDK instalado globalmente (versión 2.237.1 o superior). Este se instala a nivel global en tu máquina, no dentro del proyecto:

npm install -g aws-cdk
cdk --version

Si prefieres Python, Lambda Durable Functions también soporta Python 3.11+. Pero para este tutorial vamos con TypeScript porque es el lenguaje que más uso y el que me resulta más natural para explicar.

Creando tu primer proyecto

Abre Kiro y crea una carpeta nueva para tu proyecto. Luego, en el chat del agente, puedes pedirle directamente:

"Crea un proyecto de Lambda Durable Function con TypeScript y CDK"

El agente, con el Power instalado, va a:

Inicializar el proyecto con la estructura correcta
Instalar las dependencias necesarias
Configurar TypeScript
Crear los archivos base

Pero para que entiendas qué está pasando, vamos a hacerlo paso a paso.

Inicializar el proyecto

mkdir image-processor
cd image-processor
npm init -y

Instalar dependencias

npm install @aws/durable-execution-sdk-js
npm install --save-dev @aws/durable-execution-sdk-js-testing typescript @types/node

Ese primer paquete es el SDK de Durable Execution. Es el core de las Durable Functions: lo que hace posible que tu función guarde checkpoints y sobreviva a fallos.

El segundo paquete (-testing) es para testear localmente sin necesidad de deployar a AWS.

Estructura del proyecto

Kiro va a generar esta estructura por ti cuando le pidas crear el proyecto. Pero si prefieres hacerlo manual, así es como debería verse:

image-processor/
├── src/
│   └── handler.ts          # Tu función durable
├── tests/
│   └── handler.test.ts     # Tests locales
├── infrastructure/
│   └── stack.ts             # CDK stack para deploy
├── tsconfig.json
└── package.json

Simple. Sin carpetas innecesarias. Sin archivos que no vas a usar.

Tu primera Durable Function (generada por el Power)

Ahora viene la parte divertida.

¿Recuerdas el ejemplo del artículo anterior? Un usuario sube una foto y necesitas: validar que sea una imagen válida, redimensionar a diferentes tamaños, aplicar marca de agua, generar thumbnails, y guardar en S3.

Abre el chat de Kiro y escríbele algo como:

"Crea una Durable Function que procese imágenes: validar el archivo, redimensionar, aplicar marca de agua, generar thumbnails y guardar en S3"

El agente, con el Power instalado, genera el código por ti. No copia y pega de internet. Entiende las reglas del replay model, sabe qué va dentro de un step y qué no, y estructura el workflow siguiendo las buenas prácticas del SDK.

Esto es lo que el Power generó para mí cuando le pedí exactamente eso:

...
export const handler = withDurableExecution(async (event: ImageEvent, context: DurableContext) => {
  const outputBucket = event.outputBucket ?? event.bucket;
  const outputPrefix = event.outputPrefix ?? 'processed';
  const baseName = event.key.replace(/\.[^.]+$/, '');
  const ext = event.key.match(/\.[^.]+$/)?.[0] ?? '.jpg';

  // Step 1: Validate the file
  const imageBuffer = await context.step('validate-file', async () => {
    const response = await s3.send(new GetObjectCommand({
      Bucket: event.bucket,
      Key: event.key,
    }));

    if (!response.Body) {
      throw new Error(`File not found: ${event.key}`);
    }

    const buffer = Buffer.from(await response.Body.transformToByteArray());
    const metadata = await sharp(buffer).metadata();

    if (!metadata.format || !['jpeg', 'png', 'webp', 'tiff'].includes(metadata.format)) {
      throw new Error(
        `Unsupported image format: ${metadata.format}. Supported: jpeg, png, webp, tiff`
      );
    }

    if (buffer.length > 50 * 1024 * 1024) {
      throw new Error('File exceeds 50MB limit');
    }

    context.logger.info('File validated', {
      format: metadata.format,
      width: metadata.width,
      height: metadata.height,
      size: buffer.length,
    });

    return buffer.toString('base64');
  });

  // Step 2: Resize the image
  const resizedBase64 = await context.step(
    'resize-image',
    async () => {
      const buffer = Buffer.from(imageBuffer, 'base64');
      const maxWidth = event.maxWidth ?? 1920;
      const maxHeight = event.maxHeight ?? 1080;

      const resized = await sharp(buffer)
        .resize(maxWidth, maxHeight, { fit: 'inside', withoutEnlargement: true })
        .toBuffer();

      const resizedKey = `${outputPrefix}/${baseName}-resized${ext}`;
      await s3.send(new PutObjectCommand({
        Bucket: outputBucket,
        Key: resizedKey,
        Body: resized,
        ContentType: `image/${ext.replace('.', '')}`,
      }));

      context.logger.info('Image resized', { key: resizedKey });
      return resized.toString('base64');
    },
    { retryStrategy }
  );
...

Ver codigo completo: https://github.com/hsaenzG/durable-funtions-demo/blob/main/src/handler.ts

Parece código normal, ¿verdad? Y lo es. Pero con superpoderes.

Qué está pasando aquí

Cada context.step() es un checkpoint. Si tu función falla aplicando la marca de agua (paso 3), cuando se reintente, no va a volver a validar ni redimensionar. Salta directamente al paso 3 con los resultados que ya tenía guardados.

Eso es el replay model en acción. Y para un workflow de procesamiento de imágenes, donde cada paso puede tardar segundos o minutos, no repetir trabajo es la diferencia entre una buena experiencia y una pesadilla.

Fíjate también en context.logger en lugar de console.log: es replay-aware. No duplica logs cuando la función se reintenta.

El Kiro Power y la regla de oro del Replay Model

Aquí es donde el Kiro Power realmente brilla. Porque hay una regla que la mayoría no conocemos hasta que algo se rompe:

Todo código no determinístico DEBE ir dentro de un step.

Y el Power te avisa cuando estás a punto de violar esa regla. No tienes que memorizar todos los casos. El agente los detecta y te sugiere la corrección antes de que sea un problema.

Pero, ¿por qué importa tanto esta regla?

Cuando una Durable Function se reintenta (replay), ejecuta todo el código desde el principio. Los steps que ya completaron se saltan (usa el resultado guardado). Pero el código que está fuera de los steps se ejecuta de nuevo.

Si ese código da un resultado diferente en el replay... las cosas se rompen.

¿Qué es código no determinístico? Cualquier cosa que puede dar un resultado diferente cada vez:

Date.now() → diferente cada vez
Math.random() → diferente cada vez
Llamadas a APIs externas → pueden devolver datos diferentes
Consultas a bases de datos → los datos pueden haber cambiado
Generación de UUIDs → diferente cada vez

Veamos un ejemplo concreto:

// ❌ MAL: Date.now() fuera de un step
const timestamp = Date.now(); // Diferente en cada replay
await context.step('save', async () => save(timestamp));

// ✅ BIEN: Date.now() dentro del step
const result = await context.step('save-with-timestamp', async () => {
  const timestamp = Date.now(); // Se guarda con el checkpoint
  return save(timestamp);
});

Sin el Power, descubrir este tipo de errores es prueba y error. Con el Power, el agente te lo señala mientras escribes.

Además, puedes instalar el plugin de ESLint para Durable Functions que atrapa estos errores en tiempo de desarrollo:

npm install --save-dev @aws/durable-execution-sdk-js-eslint-plugin

Testeando localmente

No necesitas hacer deploy para probar tu función. El SDK incluye un test runner local.

import { LocalDurableTestRunner } from '@aws/durable-execution-sdk-js-testing';
import { handler } from '../src/handler';

describe('Image Processing Workflow', () => {
  it('should process an image successfully', async () => {
    const runner = new LocalDurableTestRunner(handler, { skipTime: true });

    const result = await runner.run({
      input: {
        bucket: 'my-images-bucket',
        key: 'uploads/photo.jpg',
        userId: 'user-123'
      }
    });

    // Verificar que el procesamiento se completó
    expect(result.status).toBe('completed');
    expect(result.originalKey).toBe('uploads/photo.jpg');

    // Verificar que los steps se ejecutaron
    const steps = runner.getOperations();
    const validateStep = steps.find(op => op.name === 'validate-image');
    const resizeStep = steps.find(op => op.name === 'resize-image');
    const watermarkStep = steps.find(op => op.name === 'apply-watermark');
    const thumbnailStep = steps.find(op => op.name === 'generate-thumbnails');
    const saveStep = steps.find(op => op.name === 'save-to-s3');

    expect(validateStep).toBeDefined();
    expect(resizeStep).toBeDefined();
    expect(watermarkStep).toBeDefined();
    expect(thumbnailStep).toBeDefined();
    expect(saveStep).toBeDefined();
  });
});

El skipTime: true es clave: hace que los wait se salten instantáneamente en los tests.

Y fíjate que buscamos los steps por nombre, no por índice. Eso es una buena práctica que el Power te recuerda constantemente: siempre nombra tus steps de forma descriptiva.

Haciendo deploy con CDK

Ya tienes tu función funcionando localmente. Ahora toca subirla a AWS.

Para esto usamos AWS CDK, que te permite definir tu infraestructura en código (TypeScript, en nuestro caso).

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as logs from 'aws-cdk-lib/aws-logs';
import * as iam from 'aws-cdk-lib/aws-iam';

export class DurableFunctionStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Log group explícito para mejor control
    const logGroup = new logs.LogGroup(this, 'ImageProcessingLogs', {
      logGroupName: '/aws/lambda/imageProcessing',
      retention: logs.RetentionDays.ONE_WEEK,
      removalPolicy: cdk.RemovalPolicy.DESTROY,
    });

    // La función durable
    const imageFunction = new lambda.Function(this, 'ImageProcessing', {
      runtime: lambda.Runtime.NODEJS_24_X,
      handler: 'handler.handler',
      code: lambda.Code.fromAsset('dist'),
      logGroup: logGroup,
      durableConfig: {
        executionTimeout: cdk.Duration.hours(1),
        retentionPeriod: cdk.Duration.days(7),
      },
    });

    // Política de permisos para durable execution
    imageFunction.role?.addManagedPolicy(
      iam.ManagedPolicy.fromAwsManagedPolicyName(
        'service-role/AWSLambdaBasicDurableExecutionRolePolicy'
      )
    );

    // Crear alias para invocación
    const version = imageFunction.currentVersion;
    const alias = new lambda.Alias(this, 'ProdAlias', {
      aliasName: 'prod',
      version: version,
    });

    new cdk.CfnOutput(this, 'FunctionAliasArn', {
      value: alias.functionArn,
    });
  }
}

Lo que importa aquí

Hay tres cosas que no puedes olvidar al hacer deploy de una Durable Function:

durableConfig: Sin esto, tu función es una Lambda normal. El executionTimeout define cuánto tiempo máximo puede correr tu workflow (hasta 1 año). El retentionPeriod define cuánto tiempo se guardan los datos de ejecución.
AWSLambdaBasicDurableExecutionRolePolicy: Esta política le da a tu función permisos para hacer checkpoints (lambda:CheckpointDurableExecution) y leer el estado de ejecución (lambda:GetDurableExecutionState). Sin ella, los steps no pueden guardar su progreso.
ARN calificado: Las Durable Functions requieren un ARN calificado para ser invocadas. Un ARN (Amazon Resource Name) es el identificador único de un recurso en AWS. "Calificado" significa que incluye la versión o alias de la función. No puedes invocar una Durable Function con el ARN sin calificar.

# ✅ Correcto: con alias
aws lambda invoke --function-name 'MiStack-MiFuncion-abc123:prod' response.json

# ✅ Correcto: con versión
aws lambda invoke --function-name 'MiStack-MiFuncion-abc123:1' response.json

# ❌ Incorrecto: sin calificar — va a fallar
aws lambda invoke --function-name MiStack-MiFuncion-abc123 response.json

Nota: CDK genera nombres de recursos con un sufijo aleatorio (ej: ImageProcessorStack-ImageProcessor5D0B0257-lBARjqDaXdWK). Puedes encontrar el nombre exacto de tu función en el output del cdk deploy o en la consola de AWS Lambda.

Deploy

# Compilar TypeScript
npx tsc

# Deploy con CDK
cdk deploy

CDK se encarga de crear todo: la función, el rol de IAM, los permisos, el log group, la versión y el alias.

Invocando tu función

Ya está en la nube. Ahora vamos a probarla.

Primero, sube una imagen de prueba al bucket de S3 que CDK creó:

aws s3 cp tu-imagen.jpg \
  s3://TU-BUCKET-S3/photos/test.jpg \
  --profile TU-PERFIL \
  --region us-east-1

Nota: El nombre del bucket lo genera CDK automáticamente (ej: imageprocessorstack-imagebucket97210811-x5j3e61lysxh). Puedes encontrarlo en el output del cdk deploy o en la consola de S3.

Ahora sí, invoca la función:

aws lambda invoke \
  --function-name 'TU-NOMBRE-DE-FUNCION:prod' \
  --invocation-type Event \
  --durable-execution-name "test-$(date +%s)" \
  --payload '{"bucket":"TU-BUCKET-S3","key":"photos/test.jpg"}' \
  --cli-binary-format raw-in-base64-out \
  --profile TU-PERFIL \
  --region us-east-1 \
  response.json

cat response.json

Tip: Reemplaza TU-NOMBRE-DE-FUNCION, TU-BUCKET-S3 y TU-PERFIL con los valores reales de tu entorno. Revisa los outputs del cdk deploy para encontrarlos.

Algunos detalles sobre estos parámetros:

--invocation-type Event: Invoca la función de forma asíncrona. Para workflows largos como procesamiento de imágenes, esto es lo recomendado. Si quieres esperar la respuesta, usa RequestResponse.
--durable-execution-name "test-$(date +%s)": Genera un nombre único por ejecución usando un timestamp. Esto garantiza idempotencia: si invocas con el mismo nombre dos veces, la segunda no crea una ejecución nueva.
--profile y --region: Si tienes múltiples perfiles de AWS configurados, no olvides especificarlos.

Monitoreando tus ejecuciones

Ya invocaste tu función. ¿Y ahora? ¿Cómo sabes si funcionó?

No estás a ciegas. La consola de AWS Lambda tiene una interfaz dedicada para Durable Functions donde puedes ver todo lo que está pasando.

Ve a tu función en la consola y busca la pestaña Durable executions. Ahí vas a encontrar la lista de todas las ejecuciones con su estado: running, completed, failed.

Haz clic en cualquier ejecución y vas a ver el detalle completo: qué steps se completaron, cuáles fallaron, cuánto tardó cada uno, y los datos que se guardaron en cada checkpoint.

Esto es oro para debuggear. Si algo falló en el paso 3, puedes ver exactamente qué datos tenía en ese momento y qué error se produjo. Sin adivinar. Sin buscar en CloudWatch a ciegas.

Por qué esto importa si estás empezando

Sin el Power, el camino típico es: leer toda la documentación, tropezar con el replay model, configurar el proyecto a mano, y descubrir errores de deploy por prueba y error.

Con el Power, el agente te guía en cada paso. No elimina la necesidad de entender los conceptos (eso sigue siendo importante). Pero reduce drásticamente el tiempo entre "quiero aprender Durable Functions" y "tengo una funcionando en producción".

Limpieza de recursos

Si solo estás probando, recuerda eliminar los recursos para evitar cargos:

cdk destroy

Esto elimina la función Lambda, el rol de IAM, el log group, y todos los recursos asociados. CDK se encarga de todo.

Lo que aprendiste

Instalaste un Kiro Power con un clic, creaste un proyecto desde cero, dejaste que el agente generara tu primera Durable Function con el mismo ejemplo de procesamiento de imágenes del artículo anterior, entendiste la regla de oro del replay model, testeaste localmente sin deploy, y subiste todo a AWS con CDK.

De cero a producción. Con IA guiándote en cada paso.

Qué sigue

Ya tienes el workflow de procesamiento de imágenes funcionando. Pero lo construimos en el camino feliz: todo sale bien, nada falla.

En el próximo artículo vamos a romper cosas a propósito. Vamos a ver cómo los checkpoints automáticos mantienen tu progreso incluso cuando algo truena, y cómo el replay model recupera la ejecución exactamente donde quedó.

Código real. Fallos reales. Recuperación real.

¿Te resultó útil este artículo? Compártelo con tu equipo o déjame saber en los comentarios qué otros temas de serverless te gustaría que cubriera. Y si ya instalaste el Kiro Power y estás construyendo tu primera Durable Function, me encantaría escuchar tu experiencia.

AWS Lambda Durable Functions + IA: el combo que no sabías que necesitabas

Hazel Saenz — Wed, 18 Mar 2026 16:56:38 +0000

Cómo instalar y usar el nuevo Kiro Power para Lambda Durable Functions paso a paso.

En el artículo anterior vimos que Lambda Durable Functions y Step Functions no compiten. Son dos filosofías diferentes para resolver el mismo problema: orquestación de workflows.

Step Functions orquesta visualmente. Durable Functions orquesta en código.

Y prometí que en este artículo íbamos a pasar de la teoría a la práctica.

Pero hay un detalle que no mencioné:

👉 Construir tu primera Durable Function no tiene que ser complicado.

Porque desde marzo de 2026, existe un Kiro Power que te guía paso a paso. Con IA. Dentro de tu IDE.

Y eso cambia todo.

Espera... ¿qué es Kiro?

Si es la primera vez que escuchas el nombre, no te preocupes.

Kiro es un IDE creado por AWS, potenciado con IA. Piensa en él como tu editor de código, pero con un agente de IA integrado que entiende lo que estás construyendo y te ayuda a hacerlo mejor.

No es un chatbot que pega código de internet. No es un autocompletado glorificado.

Es un agente que entiende el contexto de tu proyecto, sigue buenas prácticas, y te guía mientras escribes código.

¿Qué es un Kiro Power?

Un Power es como darle superpoderes especializados al agente de IA de Kiro.

Sin un Power, el agente sabe de todo un poco. Con un Power instalado, el agente se convierte en experto en un tema específico.

Piensa en esto: si le pides a un asistente genérico que te ayude a construir una Durable Function, probablemente te dé una respuesta genérica. Puede que funcione. Puede que no.

El Lambda Durable Functions Power

El 5 de marzo de 2026, AWS lanzó el Kiro Power para Lambda Durable Functions.

No tienes que leer toda la documentación antes de empezar. El Power te da lo que necesitas, cuando lo necesitas.

Instalando el Power

Esto es la parte más fácil. Literalmente un clic.

Abre Kiro
Ve al panel de Powers (en la barra lateral)
En la sección Available, busca "Lambda Durable Functions"
Haz clic en Install

Eso es todo.

No hay configuración adicional. No hay dependencias que instalar manualmente para el Power. Una vez instalado, el agente de Kiro ya tiene acceso a toda la guía especializada.

Nota: No todos los servicios de AWS tienen un Power dedicado. Los Powers son módulos especializados que se van agregando con el tiempo. Puedes explorar los disponibles en el panel de Powers de Kiro.

Ahora sí, vamos a construir algo.

Prerequisitos

AWS CLI instalado (versión 2.33.22 o superior) y configurado con tus credenciales:

aws --version
aws sts get-caller-identity

Node.js 22+ instalado (para este tutorial usaremos TypeScript):

node --version

AWS CDK instalado globalmente (versión 2.237.1 o superior). Este se instala a nivel global en tu máquina, no dentro del proyecto:

npm install -g aws-cdk
cdk --version

Creando tu primer proyecto

Abre Kiro y crea una carpeta nueva para tu proyecto. Luego, en el chat del agente, puedes pedirle directamente:

"Crea un proyecto de Lambda Durable Function con TypeScript y CDK"

El agente, con el Power instalado, va a:

Inicializar el proyecto con la estructura correcta
Instalar las dependencias necesarias
Configurar TypeScript
Crear los archivos base

Pero para que entiendas qué está pasando, vamos a hacerlo paso a paso.

Inicializar el proyecto

mkdir image-processor
cd image-processor
npm init -y

Instalar dependencias

npm install @aws/durable-execution-sdk-js
npm install --save-dev @aws/durable-execution-sdk-js-testing typescript @types/node

Ese primer paquete es el SDK de Durable Execution. Es el core de las Durable Functions: lo que hace posible que tu función guarde checkpoints y sobreviva a fallos.

El segundo paquete (-testing) es para testear localmente sin necesidad de deployar a AWS.

Estructura del proyecto

Kiro va a generar esta estructura por ti cuando le pidas crear el proyecto. Pero si prefieres hacerlo manual, así es como debería verse:

image-processor/
├── src/
│   └── handler.ts          # Tu función durable
├── tests/
│   └── handler.test.ts     # Tests locales
├── infrastructure/
│   └── stack.ts             # CDK stack para deploy
├── tsconfig.json
└── package.json

Simple. Sin carpetas innecesarias. Sin archivos que no vas a usar.

Tu primera Durable Function (generada por el Power)

Ahora viene la parte divertida.

Abre el chat de Kiro y escríbele algo como:

"Crea una Durable Function que procese imágenes: validar el archivo, redimensionar, aplicar marca de agua, generar thumbnails y guardar en S3"

Esto es lo que el Power generó para mí cuando le pedí exactamente eso:

...
export const handler = withDurableExecution(async (event: ImageEvent, context: DurableContext) => {
  const outputBucket = event.outputBucket ?? event.bucket;
  const outputPrefix = event.outputPrefix ?? 'processed';
  const baseName = event.key.replace(/\.[^.]+$/, '');
  const ext = event.key.match(/\.[^.]+$/)?.[0] ?? '.jpg';

  // Step 1: Validate the file
  const imageBuffer = await context.step('validate-file', async () => {
    const response = await s3.send(new GetObjectCommand({
      Bucket: event.bucket,
      Key: event.key,
    }));

    if (!response.Body) {
      throw new Error(`File not found: ${event.key}`);
    }

    const buffer = Buffer.from(await response.Body.transformToByteArray());
    const metadata = await sharp(buffer).metadata();

    if (!metadata.format || !['jpeg', 'png', 'webp', 'tiff'].includes(metadata.format)) {
      throw new Error(
        `Unsupported image format: ${metadata.format}. Supported: jpeg, png, webp, tiff`
      );
    }

    if (buffer.length > 50 * 1024 * 1024) {
      throw new Error('File exceeds 50MB limit');
    }

    context.logger.info('File validated', {
      format: metadata.format,
      width: metadata.width,
      height: metadata.height,
      size: buffer.length,
    });

    return buffer.toString('base64');
  });

  // Step 2: Resize the image
  const resizedBase64 = await context.step(
    'resize-image',
    async () => {
      const buffer = Buffer.from(imageBuffer, 'base64');
      const maxWidth = event.maxWidth ?? 1920;
      const maxHeight = event.maxHeight ?? 1080;

      const resized = await sharp(buffer)
        .resize(maxWidth, maxHeight, { fit: 'inside', withoutEnlargement: true })
        .toBuffer();

      const resizedKey = `${outputPrefix}/${baseName}-resized${ext}`;
      await s3.send(new PutObjectCommand({
        Bucket: outputBucket,
        Key: resizedKey,
        Body: resized,
        ContentType: `image/${ext.replace('.', '')}`,
      }));

      context.logger.info('Image resized', { key: resizedKey });
      return resized.toString('base64');
    },
    { retryStrategy }
  );
...

Ver codigo completo: https://github.com/hsaenzG/durable-funtions-demo/blob/main/src/handler.ts

Parece código normal, ¿verdad? Y lo es. Pero con superpoderes.

Qué está pasando aquí

Fíjate también en context.logger en lugar de console.log: es replay-aware. No duplica logs cuando la función se reintenta.

El Kiro Power y la regla de oro del Replay Model

Aquí es donde el Kiro Power realmente brilla. Porque hay una regla que la mayoría no conocemos hasta que algo se rompe:

Todo código no determinístico DEBE ir dentro de un step.

Y el Power te avisa cuando estás a punto de violar esa regla. No tienes que memorizar todos los casos. El agente los detecta y te sugiere la corrección antes de que sea un problema.

Pero, ¿por qué importa tanto esta regla?

Si ese código da un resultado diferente en el replay... las cosas se rompen.

¿Qué es código no determinístico? Cualquier cosa que puede dar un resultado diferente cada vez:

Date.now() → diferente cada vez
Math.random() → diferente cada vez
Llamadas a APIs externas → pueden devolver datos diferentes
Consultas a bases de datos → los datos pueden haber cambiado
Generación de UUIDs → diferente cada vez

Veamos un ejemplo concreto:

// ❌ MAL: Date.now() fuera de un step
const timestamp = Date.now(); // Diferente en cada replay
await context.step('save', async () => save(timestamp));

// ✅ BIEN: Date.now() dentro del step
const result = await context.step('save-with-timestamp', async () => {
  const timestamp = Date.now(); // Se guarda con el checkpoint
  return save(timestamp);
});

Sin el Power, descubrir este tipo de errores es prueba y error. Con el Power, el agente te lo señala mientras escribes.

Además, puedes instalar el plugin de ESLint para Durable Functions que atrapa estos errores en tiempo de desarrollo:

npm install --save-dev @aws/durable-execution-sdk-js-eslint-plugin

Testeando localmente

No necesitas hacer deploy para probar tu función. El SDK incluye un test runner local.

import { LocalDurableTestRunner } from '@aws/durable-execution-sdk-js-testing';
import { handler } from '../src/handler';

describe('Image Processing Workflow', () => {
  it('should process an image successfully', async () => {
    const runner = new LocalDurableTestRunner(handler, { skipTime: true });

    const result = await runner.run({
      input: {
        bucket: 'my-images-bucket',
        key: 'uploads/photo.jpg',
        userId: 'user-123'
      }
    });

    // Verificar que el procesamiento se completó
    expect(result.status).toBe('completed');
    expect(result.originalKey).toBe('uploads/photo.jpg');

    // Verificar que los steps se ejecutaron
    const steps = runner.getOperations();
    const validateStep = steps.find(op => op.name === 'validate-image');
    const resizeStep = steps.find(op => op.name === 'resize-image');
    const watermarkStep = steps.find(op => op.name === 'apply-watermark');
    const thumbnailStep = steps.find(op => op.name === 'generate-thumbnails');
    const saveStep = steps.find(op => op.name === 'save-to-s3');

    expect(validateStep).toBeDefined();
    expect(resizeStep).toBeDefined();
    expect(watermarkStep).toBeDefined();
    expect(thumbnailStep).toBeDefined();
    expect(saveStep).toBeDefined();
  });
});

El skipTime: true es clave: hace que los wait se salten instantáneamente en los tests.

Y fíjate que buscamos los steps por nombre, no por índice. Eso es una buena práctica que el Power te recuerda constantemente: siempre nombra tus steps de forma descriptiva.

Haciendo deploy con CDK

Ya tienes tu función funcionando localmente. Ahora toca subirla a AWS.

Para esto usamos AWS CDK, que te permite definir tu infraestructura en código (TypeScript, en nuestro caso).

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as logs from 'aws-cdk-lib/aws-logs';
import * as iam from 'aws-cdk-lib/aws-iam';

export class DurableFunctionStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Log group explícito para mejor control
    const logGroup = new logs.LogGroup(this, 'ImageProcessingLogs', {
      logGroupName: '/aws/lambda/imageProcessing',
      retention: logs.RetentionDays.ONE_WEEK,
      removalPolicy: cdk.RemovalPolicy.DESTROY,
    });

    // La función durable
    const imageFunction = new lambda.Function(this, 'ImageProcessing', {
      runtime: lambda.Runtime.NODEJS_24_X,
      handler: 'handler.handler',
      code: lambda.Code.fromAsset('dist'),
      logGroup: logGroup,
      durableConfig: {
        executionTimeout: cdk.Duration.hours(1),
        retentionPeriod: cdk.Duration.days(7),
      },
    });

    // Política de permisos para durable execution
    imageFunction.role?.addManagedPolicy(
      iam.ManagedPolicy.fromAwsManagedPolicyName(
        'service-role/AWSLambdaBasicDurableExecutionRolePolicy'
      )
    );

    // Crear alias para invocación
    const version = imageFunction.currentVersion;
    const alias = new lambda.Alias(this, 'ProdAlias', {
      aliasName: 'prod',
      version: version,
    });

    new cdk.CfnOutput(this, 'FunctionAliasArn', {
      value: alias.functionArn,
    });
  }
}

Lo que importa aquí

Hay tres cosas que no puedes olvidar al hacer deploy de una Durable Function:

durableConfig: Sin esto, tu función es una Lambda normal. El executionTimeout define cuánto tiempo máximo puede correr tu workflow (hasta 1 año). El retentionPeriod define cuánto tiempo se guardan los datos de ejecución.
AWSLambdaBasicDurableExecutionRolePolicy: Esta política le da a tu función permisos para hacer checkpoints (lambda:CheckpointDurableExecution) y leer el estado de ejecución (lambda:GetDurableExecutionState). Sin ella, los steps no pueden guardar su progreso.
ARN calificado: Las Durable Functions requieren un ARN calificado para ser invocadas. Un ARN (Amazon Resource Name) es el identificador único de un recurso en AWS. "Calificado" significa que incluye la versión o alias de la función. No puedes invocar una Durable Function con el ARN sin calificar.

# ✅ Correcto: con alias
aws lambda invoke --function-name 'MiStack-MiFuncion-abc123:prod' response.json

# ✅ Correcto: con versión
aws lambda invoke --function-name 'MiStack-MiFuncion-abc123:1' response.json

# ❌ Incorrecto: sin calificar — va a fallar
aws lambda invoke --function-name MiStack-MiFuncion-abc123 response.json

Nota: CDK genera nombres de recursos con un sufijo aleatorio (ej: ImageProcessorStack-ImageProcessor5D0B0257-lBARjqDaXdWK). Puedes encontrar el nombre exacto de tu función en el output del cdk deploy o en la consola de AWS Lambda.

Deploy

# Compilar TypeScript
npx tsc

# Deploy con CDK
cdk deploy

CDK se encarga de crear todo: la función, el rol de IAM, los permisos, el log group, la versión y el alias.

Invocando tu función

Ya está en la nube. Ahora vamos a probarla.

Primero, sube una imagen de prueba al bucket de S3 que CDK creó:

aws s3 cp tu-imagen.jpg \
  s3://TU-BUCKET-S3/photos/test.jpg \
  --profile TU-PERFIL \
  --region us-east-1

Nota: El nombre del bucket lo genera CDK automáticamente (ej: imageprocessorstack-imagebucket97210811-x5j3e61lysxh). Puedes encontrarlo en el output del cdk deploy o en la consola de S3.

Ahora sí, invoca la función:

aws lambda invoke \
  --function-name 'TU-NOMBRE-DE-FUNCION:prod' \
  --invocation-type Event \
  --durable-execution-name "test-$(date +%s)" \
  --payload '{"bucket":"TU-BUCKET-S3","key":"photos/test.jpg"}' \
  --cli-binary-format raw-in-base64-out \
  --profile TU-PERFIL \
  --region us-east-1 \
  response.json

cat response.json

Tip: Reemplaza TU-NOMBRE-DE-FUNCION, TU-BUCKET-S3 y TU-PERFIL con los valores reales de tu entorno. Revisa los outputs del cdk deploy para encontrarlos.

Algunos detalles sobre estos parámetros:

--invocation-type Event: Invoca la función de forma asíncrona. Para workflows largos como procesamiento de imágenes, esto es lo recomendado. Si quieres esperar la respuesta, usa RequestResponse.
--durable-execution-name "test-$(date +%s)": Genera un nombre único por ejecución usando un timestamp. Esto garantiza idempotencia: si invocas con el mismo nombre dos veces, la segunda no crea una ejecución nueva.
--profile y --region: Si tienes múltiples perfiles de AWS configurados, no olvides especificarlos.

Monitoreando tus ejecuciones

Ya invocaste tu función. ¿Y ahora? ¿Cómo sabes si funcionó?

No estás a ciegas. La consola de AWS Lambda tiene una interfaz dedicada para Durable Functions donde puedes ver todo lo que está pasando.

Ve a tu función en la consola y busca la pestaña Durable executions. Ahí vas a encontrar la lista de todas las ejecuciones con su estado: running, completed, failed.

Haz clic en cualquier ejecución y vas a ver el detalle completo: qué steps se completaron, cuáles fallaron, cuánto tardó cada uno, y los datos que se guardaron en cada checkpoint.

Esto es oro para debuggear. Si algo falló en el paso 3, puedes ver exactamente qué datos tenía en ese momento y qué error se produjo. Sin adivinar. Sin buscar en CloudWatch a ciegas.

Por qué esto importa si estás empezando

Sin el Power, el camino típico es: leer toda la documentación, tropezar con el replay model, configurar el proyecto a mano, y descubrir errores de deploy por prueba y error.

Limpieza de recursos

Si solo estás probando, recuerda eliminar los recursos para evitar cargos:

cdk destroy

Esto elimina la función Lambda, el rol de IAM, el log group, y todos los recursos asociados. CDK se encarga de todo.

Lo que aprendiste

De cero a producción. Con IA guiándote en cada paso.

Qué sigue

Ya tienes el workflow de procesamiento de imágenes funcionando. Pero lo construimos en el camino feliz: todo sale bien, nada falla.

Código real. Fallos reales. Recuperación real.

Cold Starts en AWS Lambda: Qué son, por qué ocurren y cómo solucionarlos

Hazel Saenz — Mon, 16 Mar 2026 17:08:25 +0000

Todo lo que necesitas saber sobre cold starts en Lambda y las estrategias para reducir su impacto.

La primera vez que me topé con un cold start, no tenía idea de qué estaba pasando.

Había terminado de deployar una API con Lambda para un proyecto en el que estaba trabajando. Todo funcionaba. Los tests pasaban. El endpoint respondía rápido. Estaba feliz.

Hasta que un compañero me escribió: "Oye, a veces la API tarda como 3 segundos en responder. ¿Es normal?"

Mi primera reacción fue: "No puede ser, a mí me responde en 200ms". Así que abrí CloudWatch, empecé a revisar los logs... y ahí lo vi. Un INIT duration de 2.8 segundos que aparecía de vez en cuando, sin patrón aparente. No había error. No había timeout. Solo... lentitud.

Pasé un buen rato buscando qué significaba ese INIT. ¿Era un bug? ¿Algo que configuré mal? ¿Un problema de red?

No. Era un cold start.

Y cuando entendí qué era y por qué pasaba, todo empezó a tener sentido. Esas peticiones lentas no eran aleatorias. Eran el precio de no tener servidores corriendo 24/7.

Si alguna vez sentiste que tu función Lambda "se dormía" y tardaba en despertar, este artículo es para ti. Te voy a contar todo lo que aprendí sobre cold starts: qué son, por qué ocurren, y las estrategias que uso para reducir su impacto.

¿Qué es un cold start?

Cuando invocas una función Lambda, AWS necesita un lugar donde ejecutar tu código. Ese lugar se llama execution environment: un contenedor aislado con su runtime, tu código, y las dependencias que necesita.

Si ya existe un environment disponible (porque tu función se ejecutó hace poco), Lambda lo reutiliza. Eso es un warm start. Rápido. Sin sorpresas.

Pero si no hay ninguno disponible — porque es la primera invocación, porque pasó mucho tiempo sin actividad, o porque hay un pico de tráfico y Lambda necesita crear más environments — entonces tiene que crear uno nuevo desde cero.

Eso es un cold start.

Y crear un environment desde cero no es instantáneo. Lambda tiene que hacer varias cosas antes de que tu código empiece a ejecutarse:

Container Provisioning: asignar los recursos de cómputo según la memoria configurada
Runtime Initialization: cargar el runtime del lenguaje (Python, Node.js, Java, etc.)
Function Code Loading: descargar y desempaquetar tu código
Dependency Resolution: cargar las librerías y paquetes que tu función necesita

Todo eso es la fase de inicialización (Init phase). Y esa latencia adicional es lo que llamamos cold start.

La buena noticia: el cold start solo ocurre una vez por ciclo de vida del environment. Una vez que el environment está listo, las siguientes invocaciones son warm starts.

La otra buena noticia: según AWS, los cold starts típicamente afectan menos del 1% de las invocaciones. Pero ese 1% puede ser un problema si tu aplicación es sensible a la latencia.

¿Por qué ocurren?

Los cold starts no son un bug. Son una consecuencia natural de cómo funciona el modelo serverless.

Eficiencia de recursos: no pagas cuando tu código no se ejecuta. Eso es genial para tu billetera, pero significa que Lambda apaga los environments que llevan tiempo sin usarse. Cuando llega una nueva invocación, tiene que crear uno nuevo.

Aislamiento de seguridad: cada execution environment es independiente. No comparte memoria ni estado con otros. Esa seguridad requiere crear un environment fresco cada vez.

Auto-scaling: cuando llega un pico de tráfico, Lambda crea nuevos environments para manejar la carga. Cada environment nuevo pasa por la fase de inicialización.

En resumen: los cold starts son el precio que pagas por no tener que administrar servidores. Y en la mayoría de los casos, es un precio muy bajo.

Pero cuando sí importa — APIs de usuario, microservicios interactivos, flujos donde cada segundo cuenta — necesitas saber cómo reducirlos.

Factores que influyen en la duración

No todos los cold starts son iguales. Algunos duran 100 milisegundos. Otros duran 5 segundos. La diferencia depende de varios factores.

Runtime

Los lenguajes interpretados como Python y Node.js inicializan más rápido que los compilados como Java o .NET.

¿Por qué? Java necesita cargar la JVM y hacer JIT compilation. .NET tiene un proceso similar. Python y Node.js simplemente cargan el intérprete y empiezan a ejecutar.

Eso no significa que debas elegir tu lenguaje solo por el cold start. Pero es un factor a considerar si la latencia es crítica.

Tamaño del paquete

Más grande el paquete = más tiempo para descargarlo, descomprimirlo e inicializarlo.

Si tu función incluye dependencias que no usa, estás pagando cold start por código que nunca se ejecuta. Un paquete de 5 MB inicializa mucho más rápido que uno de 250 MB.

Memoria asignada

Esto es contraintuitivo: más memoria = cold starts más rápidos.

¿Por qué? Porque Lambda asigna CPU proporcionalmente a la memoria. Más memoria significa más CPU, y más CPU significa que la inicialización se completa más rápido.

A veces, subir la memoria de 128 MB a 512 MB reduce el cold start significativamente, y el costo adicional es mínimo porque la función termina más rápido.

Configuración de red (VPC)

Si tu función está dentro de una VPC, Lambda necesita crear una Elastic Network Interface (ENI) para conectarla a la red. Eso agrega latencia al cold start.

AWS mejoró esto significativamente con Hyperplane, que redujo la latencia de VPC de segundos a milisegundos. Pero sigue siendo un factor si tu función necesita acceso a recursos dentro de una VPC.

Inicialización estática

Todo el código que se ejecuta fuera del handler se ejecuta durante la fase Init. Si estás importando 15 librerías, creando conexiones a bases de datos, y cargando archivos de configuración... todo eso suma al cold start.

# Todo esto se ejecuta durante el Init (cold start)
import pandas as pd
import numpy as np
import boto3
from langchain import LLMChain

s3_client = boto3.client('s3')
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('my-table')

def lambda_handler(event, context):
    # Esto se ejecuta en cada invocación (warm o cold)
    ...

La inicialización estática es un arma de doble filo: quieres inicializar cosas fuera del handler para reutilizarlas en warm starts, pero todo lo que pongas ahí aumenta el cold start.

Estrategias de optimización (sin costo adicional)

Antes de llegar a las soluciones de AWS que cuestan dinero, hay varias cosas que puedes hacer gratis.

1. Importa solo lo necesario

# ❌ Importa todo el SDK
import boto3

# ✅ Importa solo lo que necesitas
from boto3 import client
s3 = client('s3')

2. Mantén tus paquetes pequeños

Elimina dependencias que no uses. Usa tree shaking en Node.js. Excluye archivos de tests, documentación, y ejemplos de tus paquetes de deployment.

3. Inicializa clientes fuera del handler

# ✅ Se inicializa una vez y se reutiliza en warm starts
s3_client = boto3.client('s3')

def lambda_handler(event, context):
    response = s3_client.get_object(Bucket='my-bucket', Key='my-key')
    ...

4. Asigna memoria adecuada

No te quedes con los 128 MB por defecto si tu función carga dependencias pesadas. Experimenta con 256 MB, 512 MB, o más. Usa AWS Lambda Power Tuning para encontrar el balance óptimo entre costo y rendimiento.

5. Usa layers para dependencias compartidas

Si varias funciones usan las mismas dependencias, empaquétalas en un Lambda Layer. Esto no reduce el cold start directamente, pero te ayuda a mantener paquetes organizados y más fáciles de optimizar.

Provisioned Concurrency: environments siempre calientes

Si las optimizaciones de código no son suficientes, AWS tiene dos soluciones dedicadas. La primera es Provisioned Concurrency.

La idea es simple: le dices a Lambda "mantén X environments siempre listos". Lambda los pre-inicializa y los mantiene calientes, esperando invocaciones.

Resultado: cero cold starts para esas invocaciones. Respuestas en milisegundos de doble dígito.

# Configurar 10 environments siempre listos
aws lambda put-provisioned-concurrency-config \
  --function-name my-function \
  --qualifier prod \
  --provisioned-concurrent-executions 10

Cuándo usarlo

Tu aplicación tiene requisitos estrictos de latencia (APIs de usuario, microservicios interactivos)
El tráfico es predecible o puedes configurar auto-scaling
Estás dispuesto a pagar por environments que están listos aunque no se usen

Cuándo NO usarlo

Tráfico esporádico o impredecible (vas a pagar por environments idle)
Workloads asíncronos donde la latencia no es crítica (procesamiento de datos, colas)
Tu presupuesto es ajustado

Nota importante: Provisioned Concurrency tiene un costo adicional. Pagas por cada environment provisionado, esté o no procesando invocaciones. Pero si la latencia es crítica para tu negocio, el costo vale la pena.

También puedes combinar Provisioned Concurrency con Application Auto Scaling para ajustar automáticamente la cantidad de environments según el tráfico. Puedes usar scheduled scaling (para patrones predecibles) o target tracking (para ajuste dinámico).

SnapStart: snapshots del environment inicializado

La segunda solución es Lambda SnapStart. Y funciona de una manera completamente diferente.

En lugar de mantener environments calientes, SnapStart toma una foto (snapshot) del environment después de que se inicializa. Cuando llega una invocación, en lugar de inicializar desde cero, Lambda restaura el environment desde esa foto.

El resultado: cold starts que bajan de varios segundos a sub-segundo.

Runtimes soportados

Java 11+
Python 3.12+
.NET 8+

Cuándo usarlo

Funciones con inicialización pesada (dependencias grandes, frameworks, modelos ML)
Invocaciones frecuentes a escala
Quieres reducir cold starts sin el costo de Provisioned Concurrency

Cuándo NO usarlo

Funciones que ya inicializan en milisegundos (no vas a notar la diferencia)
Necesitas latencia garantizada de doble dígito de milisegundos (usa Provisioned Concurrency)
Tu función usa EFS, Provisioned Concurrency, o almacenamiento efímero mayor a 512 MB (no es compatible)

SnapStart es especialmente interesante para Python, donde cargar dependencias como Pandas, NumPy, LangChain, o frameworks como Flask y Django puede tomar varios segundos.

👉 En el próximo artículo de esta serie, vamos a profundizar en SnapStart para Python: cómo funciona internamente, cómo activarlo paso a paso, cómo usar runtime hooks, y las mejores prácticas para sacarle el máximo provecho.

¿Cuál estrategia elegir?

No es "una u otra". Puedes (y deberías) combinarlas.

Estrategia	Latencia	Costo adicional	Ideal para
Optimización de código	Reduce el Init	Ninguno	Siempre. Es el primer paso
SnapStart	Sub-segundo	Costo de cache + restauración	Funciones con init pesado a escala
Provisioned Concurrency	Milisegundos	Pago por environment provisionado	Latencia ultra-baja garantizada

La recomendación:

Siempre optimiza tu código primero. Es gratis y ayuda en todos los escenarios.
Si después de optimizar sigues teniendo cold starts largos y tu función se invoca frecuentemente, prueba SnapStart.
Si necesitas latencia garantizada de milisegundos sin excepciones, usa Provisioned Concurrency.

📊 Árbol de decisión (haz clic para expandir)

Monitoreo: cómo saber si tienes un problema

Antes de optimizar, necesitas medir. No asumas que tienes un problema de cold starts solo porque "a veces se siente lento".

Si quieres ir más a fondo en el tema de diagnóstico y optimización de rendimiento en Lambda, te recomiendo este artículo donde comparto mi experiencia: Eleva el rendimiento de AWS Lambda. Ahí cubro métricas de invocación, benchmarks, y estrategias prácticas para llevar tus funciones al siguiente nivel.

Lo que aprendiste

Los cold starts son parte natural del modelo serverless. No son un bug, son un trade-off por no administrar servidores. Afectan menos del 1% de las invocaciones, pero cuando importan, importan mucho.

La duración depende del runtime, el tamaño del paquete, la memoria asignada, y la configuración de red. Optimizar el código es siempre el primer paso y no cuesta nada. Provisioned Concurrency y SnapStart son las dos soluciones de AWS cuando necesitas ir más allá.

Qué sigue

Ya entiendes qué son los cold starts y las estrategias para combatirlos. En el próximo artículo vamos a profundizar en Lambda SnapStart para Python: cómo funciona por debajo (Firecracker snapshots, cache en dos niveles), cómo activarlo paso a paso, cómo usar runtime hooks, y las mejores prácticas para sacarle el máximo provecho a tus funciones Python.

Código real. Configuración real. Resultados reales.

¿Te resultó útil este artículo? Compártelo con tu equipo o déjame saber en los comentarios qué otros temas de serverless te gustaría que cubriera. Y si ya estás lidiando con cold starts en producción, me encantaría escuchar cómo los resolviste.

Lambda Durable Functions mata a Step Functions... ¿o no?

Hazel Saenz — Thu, 12 Mar 2026 00:26:59 +0000

La verdad sobre cuándo usar cada una (y por qué necesitas entender ambas).

Al final de este artículo, sabrás exactamente cuándo elegir cada una.

Cuando AWS anunció Lambda Durable Functions en re:Invent 2025, mi primera reacción fue:

"Espera... ¿no es eso lo que hace Step Functions?"

Y no fui la única. En conversaciones con otros devs, la pregunta era siempre la misma:

¿Por qué dos herramientas para lo mismo?

Si ya tengo Step Functions orquestando workflows, ¿para qué necesito Durable Functions? ¿Es un reemplazo? ¿Debería migrar todo? Pasé días leyendo la documentación, probando ejemplos, y tratando de entender la diferencia real. Y descubrí algo que casi nadie estaba diciendo:

No son lo mismo. Ni siquiera intentan serlo.

La respuesta corta: No

Lambda Durable Functions no mata a Step Functions. Son dos filosofías diferentes para resolver el mismo problema. Step Functions orquesta visualmente, Durable Functions orquesta en código. Y aquí está lo interesante: ambas tienen su lugar. No es "una u otra". Es "cuál para qué".

El problema que ambas resuelven

Antes de hablar de diferencias, hay que entender qué problema están resolviendo.

Imagina que estás construyendo un sistema de procesamiento de imágenes. Un usuario sube una foto y necesitas:

Validar que el archivo es una imagen válida
Redimensionar a diferentes tamaños
Aplicar marca de agua
Generar thumbnails
Optimizar y guardar en S3

Suena simple, ¿no?

Pero cada paso puede fallar.

Cada paso puede tardar segundos... o minutos.

Y necesitas mantener el estado del procesamiento a través de todo el flujo.

Si la validación falla, no puedes continuar.

Si el redimensionamiento truena, necesitas reintentarlo sin volver a validar.

Si algo falla a la mitad, necesitas saber exactamente dónde quedó todo.

Esto es orquestación de workflows: coordinar múltiples pasos sin perder el estado, manejando errores y reintentos de forma elegante.

Tanto Step Functions como Durable Functions resuelven esto. Pero lo hacen de maneras completamente diferentes.

Step Functions: El enfoque visual

Step Functions es declarativo. Eso significa que defines qué debe pasar, no cómo hacerlo. Piensa en pedir un Uber: dices "llévame al aeropuerto" y alguien más decide la ruta, los giros, las autopistas. Tú solo declaras el destino.

Así se ve un workflow en Step Functions:

En el código del workflow en Step Functions no estás escribiendo código que ejecuta cada paso. Estás describiendo el flujo. Y AWS se encarga del resto: mantener el estado, manejar errores, reintentar cuando falla algo.

{
  "StartAt": "ValidateImage",
  "States": {
    "ValidateImage": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:function:ValidateImage",
      "Next": "ResizeImage"
    },
    "ResizeImage": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:function:ResizeImage",
      "Next": "ApplyWatermark"
    },
    "ApplyWatermark": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:function:ApplyWatermark",
      "Next": "GenerateThumbnails"
    },
    "GenerateThumbnails": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:function:GenerateThumbnails",
      "Next": "SaveToS3"
    },
    "SaveToS3": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:function:SaveToS3",
      "End": true
    }
  }
}

Cuándo brilla Step Functions

Hay escenarios donde este enfoque visual es perfecto:

Workflows con múltiples ramas y condiciones complejas
Si tu flujo tiene muchos "si esto, entonces aquello", Step Functions te deja verlo todo de un vistazo.
Equipos no técnicos necesitan entender la lógica
Product managers, QA, stakeholders... todos pueden abrir la consola de AWS y ver exactamente qué está pasando.
El workflow cambia frecuentemente
Ajustar un JSON es más rápido que reescribir código, hacer tests y deployar.
Integraciones directas con servicios AWS
DynamoDB, SNS, SQS... Step Functions los conecta sin escribir código.

Lambda Durable Functions: El enfoque code-first

Durable Functions es completamente diferente. Aquí no describes el flujo. Lo escribes.

Es code-first: código que ejecuta paso a paso, con checkpoints automáticos que mantienen el estado. Siguiendo la analogía del Uber: aquí tú manejas. Gira a la izquierda, sigue derecho tres cuadras, toma la autopista, sal en la salida 12. Tú controlas cada paso del camino.

Así se ve el mismo workflow en Durable Functions:

import { withDurableExecution, DurableContext } from '@aws/durable-execution-sdk-js';

export const handler = withDurableExecution(async (event, context: DurableContext) => {
    // Cada step es un checkpoint automático
    const validated = await context.step('validate-image', async () => 
        validateImage(event)
    );
    const resized = await context.step('resize-image', async () => 
        resizeImage(validated)
    );
    const watermarked = await context.step('apply-watermark', async () => 
        applyWatermark(resized)
    );

    return { status: "completed", result: watermarked };
});

Parece código normal, ¿verdad? Y lo es. Pero con un superpoder: cada step es un checkpoint. Si algo falla, el workflow se reanuda exactamente donde quedó. No pierdes estado. No repites trabajo.

Cuándo brilla Durable Functions

Este enfoque tiene sus propios momentos de gloria:

Workflows secuenciales con lógica compleja
Si tu flujo es más "haz esto, luego esto, luego esto" y menos "si esto entonces aquello", el código es más natural.
Tu equipo vive en el IDE
Developers que prefieren escribir código, hacer tests unitarios, usar breakpoints... esto se siente como casa.
Necesitas reutilizar lógica existente
Si ya tienes funciones de negocio en tu codebase, las puedes llamar directamente.
Transformaciones de datos complejas entre pasos
Escribir esa lógica en código es más claro que en JSON.

Las diferencias que importan

Ahora que viste ambos enfoques, aquí están las diferencias que realmente afectan tu decisión:

Aspecto	Step Functions	Durable Functions
Modelo	Declarativo (JSON/YAML)	Code-first (Python, Node.js, etc.)
Visualización	Nativa en consola AWS	Requiere herramientas externas
Debugging	Logs y trazas visuales	Breakpoints tradicionales
Complejidad	Excelente para flujos con branches	Excelente para lógica secuencial
Curva de aprendizaje	Sintaxis específica de ASL	Tu lenguaje de programación
Límite de payload	256 KB entre estados	6 MB entre pasos

No es que una sea mejor que la otra. Es que cada una brilla en escenarios diferentes.

El límite de payload: un detalle que importa

Hay algo que muchos descubren tarde: Step Functions tiene un límite de 256 KB para los datos que pasan entre estados.

Suena como mucho, hasta que no lo es.

Imagina que estás procesando una imagen grande con metadata extensa. O generando múltiples variaciones con información de cada una. O trabajando con respuestas de APIs que devuelven arrays grandes de datos de procesamiento.

De repente, ese límite de 256 KB se siente pequeño.

La solución típica es guardar los datos en S3 y pasar solo la referencia:

{
  "imageLocation": "s3://my-bucket/processed/image-123.jpg",
  "metadata": {
    "width": 1920,
    "height": 1080
  }
}

Funciona, pero agrega complejidad: más código, más servicios, más cosas que pueden fallar.

Durable Functions tiene un límite mucho más generoso: 6 MB entre pasos. Eso es 24 veces más espacio.

No significa que debas pasar 6 MB de datos entre pasos (probablemente no deberías). Pero sí significa que tienes más margen antes de necesitar workarounds.

Si tu workflow maneja datos grandes, esta diferencia puede ser decisiva.

Cuándo usar cada una

Aquí está la parte más importante del artículo. La pregunta no es "¿cuál es mejor?" sino "¿cuál necesito para este problema específico?"

Usa AWS Step Functions cuando:

Tu workflow tiene múltiples ramas condicionales (if/else complejos) → La visualización te ayuda a no perderte.
Necesitas que stakeholders no técnicos vean y entiendan el flujo → Abrir la consola de AWS es más fácil que explicar código.
El workflow cambia frecuentemente → Ajustar JSON es más rápido que reescribir, testear y deployar código.
Quieres visualización nativa sin configuración adicional → AWS te da todo out-of-the-box.
Trabajas con servicios AWS que tienen integraciones directas → DynamoDB, SNS, SQS... Step Functions los conecta sin escribir código.

Usa Durable Functions cuando:

Tu workflow es principalmente secuencial con lógica compleja → El código es más natural que describir cada paso en JSON.
Tu equipo prefiere trabajar completamente en código → IDE, tests unitarios, control de versiones... todo en un solo lugar.
Necesitas reutilizar lógica de negocio existente → Llamas funciones que ya tienes, sin adaptarlas.
Quieres debugging tradicional con breakpoints → Step-through, inspección de variables, todo lo que ya conoces.
El workflow requiere transformaciones de datos complejas entre pasos → Escribir esa lógica en código es más claro que en JSON.

Si después de leer esto sigues sin estar seguro... probablemente Step Functions es tu mejor opción. La visualización ayuda más de lo que crees cuando estás empezando.

Y si quieres una forma rápida de recordarlo:

📊 *Árbol de decisión *
Te dejo este árbol de decisión que puedes guardar o imprimir para tenerlo a mano cuando necesites elegir:

La verdad: se complementan

Aquí está el secreto que casi nadie menciona: Puedes usar ambas en la misma arquitectura. Imagina una arquitectura donde:

Step Functions orquesta el flujo principal de la aplicación:

→ Recibe la imagen
→ Valida formato
→ Procesa transformaciones
→ Notifica al usuario

Durable Functions maneja sub-procesos complejos dentro de cada paso:

→ Aplicar múltiples filtros con lógica compleja
→ Detección de contenido con reglas de negocio
→ Transformaciones de metadata entre sistemas

Step Functions te da la vista de 10,000 pies. Durable Functions te da el control fino donde lo necesitas. Algunos problemas se resuelven mejor con visualización. Otros se resuelven mejor con código.

Y ahora tienes ambas opciones.

Este es el primer artículo de una serie donde vamos a explorar Durable Functions en profundidad:

Construye tu primera AWS Lambda Durable Function: Instalación, setup y tu primer workflow funcional paso a paso
Multi-step workflows que sobreviven fallos: Cómo los checkpoints automáticos mantienen tu progreso incluso cuando algo truena
Callbacks y aprobaciones externas: Pausar workflows esperando input humano o eventos externos
Waits y condiciones: Suspender ejecución por horas o días sin pagar por tiempo idle
Ejecución en paralelo: Correr múltiples pasos al mismo tiempo y coordinar resultados

La pregunta no es "¿cuál va a sobrevivir?" Es "¿cuál necesito para este problema específico?" Y ahora ya sabes cómo responderla.

¿Qué viene después?

En el próximo artículo, vamos a construir tu primera AWS Lambda Durable Function desde cero: instalación, setup y un workflow funcional paso a paso. Código real, problemas reales, soluciones reales.

¿Te resultó útil este artículo? Compártelo con tu equipo o déjame saber en los comentarios qué otros temas de serverless te gustaría que cubriera. Y si ya estás usando Step Functions o Durable Functions en producción, me encantaría escuchar tu experiencia.

Amazon API Gateway: La puerta de entrada a tu backend en la nube

Hazel Saenz — Tue, 03 Mar 2026 14:57:58 +0000

Cómo API Gateway recibe requests y los conecta con tu lógica de backend.

Ya sabes qué es una API y por qué las aplicaciones se comunican haciendo peticiones.
Ya entiendes cómo una petición viaja desde tu app hasta el servidor.
Ya viste qué es REST y cómo el backend interpreta esa petición y decide qué responder.

Pero quedó una pregunta sin responder:

👉 ¿Cómo se implementa todo esto en la nube?

Porque una cosa es entender el concepto de una API REST, y otra muy distinta es desplegarla, gestionarla, escalarla, y mantenerla funcionando en producción.

Ahí es donde entra Amazon API Gateway.

No como una tecnología complicada que tienes que dominar desde cero. Sino como la puerta de entrada que maneja todo lo que pasa antes de que tu lógica de backend se ejecute.

Este artículo es para entender eso.

El problema que Amazon API Gateway resuelve

Imagina que construiste una aplicación que devuelve información de personajes de Harry Potter. Tu aplicación funciona perfecto: recibe un ID, busca en la base de datos, devuelve el personaje.

Pero ahora necesitas que tu app móvil pueda llamar a esa aplicación.

¿Cómo lo haces?

Podrías montar tu propio servidor. De hecho, eso es lo que los equipos hacían antes. Configuraban servidores con Nginx o Apache, instalaban load balancers, escribían reglas de enrutamiento, configuraban SSL manualmente, y monitoreaban logs constantemente.

Todo esto funcionaba. Pero requería experiencia en DevOps, mantener servidores 24/7, pagar por ellos aunque nadie los usara, y escalar manualmente cuando cambiaba el tráfico.

Amazon API Gateway elimina toda esa complejidad.

Es un servicio administrado que actúa como la puerta de entrada a tu backend. No es tu backend, no es donde vive tu lógica, no es donde guardas tus datos. Es el punto de entrada.

Piensa en API Gateway como el recepcionista de un edificio: recibe a todos los visitantes, verifica que tengan permiso, los dirige al piso correcto, pero no hace el trabajo de los que están en las oficinas.

No tienes que mantener servidores. No pagas cuando no hay tráfico. Escala automáticamente. Maneja HTTPS, configuración de seguridad para navegadores web, autenticación, y límites de peticiones por ti.

Es como tener un equipo de DevOps administrando tu puerta de entrada, pero sin tener que contratar a nadie.

Y lo más importante: te deja enfocarte en tu lógica de negocio, no en la infraestructura.

Cómo funciona el flujo básico

Cuando tu app hace una petición a una API desplegada con API Gateway:

La petición llega a API Gateway - Tu app hace un GET https://api.tuapp.com/personajes/8
API Gateway valida - Verifica que la petición esté bien formada y tenga permisos
Llama a tu backend - En este caso, ejecuta tu función Lambda
Devuelve la respuesta - Tu app recibe el JSON con la información del personaje

Todo ese proceso pasa en milisegundos.

Construyamos nuestra primera API con API Gateway + Lambda

Vamos a construir una API simple que devuelve información de un personaje de Harry Potter.

Para esto usaremos dos servicios de AWS:

AWS Lambda es un servicio que ejecuta tu código sin que tengas que administrar servidores. Tú solo subes tu código y Lambda se encarga de ejecutarlo cuando lo necesites. Aquí es donde vivirá nuestra lógica de negocio.

API Gateway será la puerta de entrada que recibe las peticiones HTTP y las conecta con nuestra función Lambda.

No te preocupes si es tu primera vez usando AWS. Vamos paso a paso.

Nota importante: Este tutorial puede realizarse completamente dentro de la capa gratuita de AWS, así que no tendrá ningún costo si tu cuenta es nueva o si no has excedido los límites gratuitos. Al final del artículo te mostraré cómo limpiar los recursos para evitar que se consuman tus créditos gratuitos (no se hará ningún cargo a tu tarjeta).

Paso 1: Crear la función Lambda

Primero necesitamos crear la función que contendrá nuestra lógica.

Crear la función:

Ve a la consola de AWS y busca "Lambda" en el buscador superior
Haz clic en "Create function" (Crear función)
Selecciona "Author from scratch" (Crear desde cero)
Configura tu función:
- Function name: obtenerPersonaje
- Runtime: Node.js 20.x (o la versión más reciente)
- Architecture: x86_64
Deja las demás opciones por defecto y haz clic en "Create function"

Agregar el código:

Una vez creada, verás el editor de código. Reemplaza el código por defecto con este:

export const handler = async (event) => {
  // Base de datos simulada de personajes
  const personajes = {
    "1": { id: 1, nombre: "Harry Potter", casa: "Gryffindor", poder: 95 },
    "2": { id: 2, nombre: "Hermione Granger", casa: "Gryffindor", poder: 98 },
    "3": { id: 3, nombre: "Ron Weasley", casa: "Gryffindor", poder: 85 },
    "8": { id: 8, nombre: "Ginny Weasley", casa: "Gryffindor", poder: 83 }
  };

  // Obtener el ID del personaje desde la petición
  const id = event.pathParameters?.id || "1";

  console.log('ID recibido:', id);

  // Buscar el personaje
  const personaje = personajes[id];

  // Si no existe, devolver error
  if (!personaje) {
    return {
      statusCode: 404,
      headers: {
        "Content-Type": "application/json"
      },
      body: JSON.stringify({ error: "Personaje no encontrado" })
    };
  }

  // Devolver el personaje encontrado
  return {
    statusCode: 200,
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify(personaje)
  };
};

Haz clic en "Deploy" para guardar los cambios

Tu función Lambda ya está lista. Ahora vamos a conectarla con API Gateway.

Paso 2: Crear la API en API Gateway

Ve a la consola de AWS y busca "API Gateway"
Haz clic en "Create API" (Crear API)
Selecciona "REST API" (no la opción Private)
Haz clic en "Build" (Crear)
Configura tu API:
- Choose the protocol: REST
- Create new API: New API
- API name: API-Personajes
- Description: API para obtener información de personajes
- Endpoint Type: Regional
Haz clic en "Create API"

Paso 3: Crear el recurso y método

Ahora vamos a definir la estructura de nuestra API.

Crear el recurso principal:

En el panel izquierdo, verás tu API. Haz clic en "Create Resource" (Crear recurso)
Configura el recurso:
- Resource Name: personajes
- Resource Path: /personajes
Marca la opción "Enable API Gateway CORS" (esto permite que tu API sea llamada desde navegadores)
Haz clic en "Create Resource"

Crear el sub-recurso con parámetro:

Con el recurso /personajes seleccionado, haz clic en "Create Resource" nuevamente para crear un sub-recurso
Configura:
- Resource Name: {id}
- Resource Path: /{id}
- Marca "Enable API Gateway CORS"
Haz clic en "Create Resource"

Ahora tienes la ruta /personajes/{id} donde {id} es un parámetro dinámico.

Crear el método GET:

Con el recurso {id} seleccionado, haz clic en "Create Method" (Crear método)
Selecciona "GET" del dropdown y haz clic en el check ✓

Configurar la integración con Lambda:

Configura la integración:
- Integration type: Lambda Function
- IMPORTANTE: Marca la casilla "Use Lambda Proxy integration"
- Lambda Region: (tu región, por ejemplo us-east-1)
- Lambda Function: obtenerPersonaje (empieza a escribir y aparecerá)
- Deja las demás opciones por defecto
Haz clic en "Save"

Nota importante sobre Lambda Proxy Integration: Esta opción le dice a API Gateway que pase toda la información de la petición HTTP (headers, path parameters, query strings, body) directamente a tu función Lambda en el objeto event. Sin esta opción, tendrías que configurar manualmente cómo se mapean los parámetros, lo cual es más complejo y propenso a errores.

Aparecerá un mensaje pidiendo permiso para que API Gateway invoque tu Lambda. Haz clic en "OK"

Este paso es importante: le estás dando permiso a API Gateway para que pueda ejecutar tu función Lambda.

Sin este permiso, API Gateway no podría llamar a tu función cuando llegue una petición.

AWS maneja esto automáticamente por ti cuando haces clic en "OK".

Paso 4: Desplegar la API

Tu API está configurada, pero aún no está disponible públicamente. Necesitas desplegarla.

Haz clic en "Deploy API" en el menú superior
Configura el despliegue:
- Deployment stage: [New Stage]
- Stage name: prod
- Stage description: Producción
Haz clic en "Deploy"

¡Listo! Tu API ya está en producción.

Paso 5: Probar tu API

API Gateway te da una URL pública para tu API.

En la pantalla de "Stages", verás tu stage "prod"
Expande el árbol: prod → /personajes → /{id} → GET
En la parte superior verás la "Invoke URL" La URL se verá algo así:

https://abc123xyz.execute-api.us-east-1.amazonaws.com/prod/personajes/8

Copia esa URL y ábrela en tu navegador (cambia el 8 por 1, 2, 3, u 8 para ver diferentes personajes)

También puedes probarla desde la terminal:

curl https://tu-url-aqui.execute-api.us-east-1.amazonaws.com/prod/personajes/8

Deberías ver una respuesta como esta:

{
  "id": 8,
  "nombre": "Ginny Weasley",
  "casa": "Gryffindor",
  "poder": 83
}

¿Qué acabas de hacer?

Acabas de construir una API REST completa en la nube:

Creaste una función Lambda con tu lógica de negocio
Configuraste API Gateway como punto de entrada
Definiste una ruta con parámetros dinámicos (/personajes/{id})
Desplegaste tu API en producción
Obtuviste una URL pública que cualquiera puede llamar

Todo sin:

Montar servidores
Configurar balanceadores de carga
Manejar certificados SSL
Escribir código de infraestructura

Eso es el poder de serverless + API Gateway.

Limpieza: Eliminar los recursos

Si solo estás probando y no quieres que estos recursos sigan activos en tu cuenta de AWS, es importante eliminarlos para evitar que se consuman tus créditos gratuitos (si estás en la capa gratuita) o para evitar cargos innecesarios.

Eliminar la API en API Gateway

Ve a la consola de API Gateway
Selecciona tu API API-Personajes
Haz clic en "Actions" → "Delete API"
Confirma escribiendo el nombre de la API y haz clic en "Delete API"

Eliminar la función Lambda

Ve a la consola de Lambda
Selecciona tu función obtenerPersonaje
Haz clic en "Actions" → "Delete"
Confirma la eliminación

Con esto, todos los recursos del tutorial están eliminados y no generarán cargos en tu cuenta.

Por qué esto importa para arquitecturas serverless

Porque en serverless, tus funciones no están "corriendo" todo el tiempo. Se ejecutan cuando las llamas. Y se apagan cuando terminan. Pero tu app necesita una URL estable. Un punto de entrada que siempre esté disponible. API Gateway es ese punto de entrada.

Tu app siempre llama a la misma URL. API Gateway siempre está ahí. Y cuando llega una petición, despierta tu Lambda, la ejecuta, y devuelve la respuesta.

Sin API Gateway, serverless no funcionaría para APIs públicas.

Lo que aprendiste

API Gateway es la puerta de entrada, no el backend.
Recibe peticiones HTTP y las conecta con tu lógica real.
Maneja validación, transformación, seguridad, y throttling.
Puede integrarse con Lambda, HTTP endpoints, o servicios de AWS.
Incluye características de gestión de APIs sin código adicional.
Es esencial para arquitecturas serverless.

No es magia. Es infraestructura que alguien más mantiene por ti.

Y esa diferencia es lo que te permite construir APIs en producción sin tener que ser experto en DevOps.

Qué sigue

API Gateway es la puerta de entrada, no el backend.
Recibe peticiones HTTP y las conecta con tu lógica real.
Maneja validación, transformación, seguridad, y límites de peticiones.
Puede integrarse con Lambda, HTTP endpoints, o servicios de AWS.
Incluye características de gestión de APIs sin código adicional.
Es esencial para arquitecturas serverless. Ahora tienes las bases para construir tus propias APIs.

No porque hayas memorizado sintaxis o comandos.

Sino porque entiendes cómo funciona la conversación de principio a fin.

Y esa claridad es lo que te permite construir mejor, debuggear más rápido, y diseñar con más confianza.

Qué es REST y cómo responde a un request

Hazel Saenz — Tue, 24 Feb 2026 20:52:08 +0000

Una explicación simple para entender cómo el backend interpreta lo que pides y decide qué responderte.

Ya sabes que las aplicaciones hacen peticiones, ya sabes que esas peticiones viajan por la red hasta llegar a un servidor, pero quedó una pregunta sin responder:

👉 ¿Qué pasa cuando la petición llega? ¿Cómo sabe el servidor qué hacer con ella?

Esa es la parte que casi nunca se explica bien. Y es justo ahí donde entra REST.

No como una tecnología mágica, no como un framework que instalas. Sino como una forma de organizar la conversación entre quien pide y quien responde.

Este artículo es para entender eso.

La petición llegó. ¿Y ahora qué?

En el artículo anterior vimos el viaje completo de una petición: desde que sale de tu app, viaja por la red, llega al servidor, y regresa con una respuesta.

Pero quedó pendiente entender qué pasa exactamente cuando esa petición llega al servidor.

Imagina que tu app envía esta petición:

GET /personajes/8

El servidor la recibe. La lee. Y tiene que decidir:

¿Qué está pidiendo?
¿Qué debería responder?
¿Cómo debería estructurar esa respuesta?

Si no hay reglas claras, cada servidor podría interpretar eso de forma diferente.

Uno podría pensar que /personajes/8 significa "dame el personaje con ID 8".
Otro podría pensar que significa "borra el personaje 8".
Otro podría no entender nada.

REST existe para evitar ese caos.

Define un conjunto de reglas que hacen que la conversación sea predecible.

REST no es una tecnología

Aquí es donde empieza la confusión.

REST no es:

Un lenguaje de programación
Un framework que instalas
Una librería que importas

REST es un estilo de comunicación.

Un acuerdo sobre cómo estructurar las peticiones y las respuestas para que ambas partes se entiendan sin necesidad de conocerse por dentro.

Piensa en REST como las reglas de una conversación educada:

Cuando preguntas algo, lo haces de forma clara
Cuando respondes, das información útil
Ambas partes saben qué esperar del otro

Eso es REST. Nada más. Nada menos.

Las peticiones expresan intención

En REST, cada petición tiene dos partes clave:

El recurso (qué estás pidiendo)
El verbo HTTP (qué quieres hacer con ese recurso)

Volviendo al ejemplo:

GET /personajes/8

Recurso: /personajes/8 (el personaje con ID 8)
Verbo: GET (quiero obtener información)

El verbo no es un comando. Es una intención.

No le estás diciendo al servidor "ejecuta esta función". Le estás diciendo "esto es lo que quiero hacer". Y el servidor decide cómo hacerlo.

Los verbos HTTP como lenguaje

REST usa los verbos HTTP para expresar intenciones comunes:

GET: "Quiero ver algo"

GET /personajes/8

"Dame información del personaje 8"

No modifica nada. Solo pide información.

POST: "Quiero crear algo nuevo"

POST /personajes
{
  "nombre": "Luna Lovegood",
  "casa": "Ravenclaw"
}

"Crea un nuevo personaje con esta información"

PUT/PATCH: "Quiero actualizar algo"

PATCH /personajes/8
{
  "poder": 90
}

"Actualiza el poder del personaje 8"

DELETE: "Quiero eliminar algo"

DELETE /personajes/8

"Elimina el personaje 8"

No tienes que memorizar esto. Solo tienes que entender que cada verbo expresa una intención diferente. Y REST usa esas intenciones para organizar la conversación.

Recursos, no acciones

Aquí hay algo importante que muchas veces se pasa por alto: En REST, las URLs representan recursos, no acciones.

Por ejemplo:

❌ Mal diseño (acciones en la URL):

POST /crearPersonaje
POST /eliminarPersonaje
POST /actualizarPersonaje

✅ Buen diseño (recursos + verbos):

POST /personajes
DELETE /personajes/8
PATCH /personajes/8

¿Ves la diferencia?

En el primer caso, la URL dice qué hacer. En el segundo caso, la URL dice sobre qué y el verbo dice qué hacer.

Esa separación hace que las APIs sean más claras y predecibles.

El servidor interpreta y decide

Cuando el servidor recibe una petición REST, sigue un proceso:

Lee el verbo: ¿Qué quiere hacer?
Lee el recurso: ¿Sobre qué?
Evalúa: ¿Tiene permiso? ¿Existe ese recurso?
Ejecuta la lógica: Busca en la base de datos, procesa, valida
Construye la respuesta: Decide qué devolver

Por ejemplo, si recibe:

GET /personajes/8

El servidor:

Identifica que es una petición GET (quiere información)
Identifica que el recurso es /personajes/8
Busca en la base de datos el personaje con ID 8
Si lo encuentra, lo devuelve
Si no lo encuentra, responde con un error

Todo eso pasa en el backend.

La app que hizo la petición no sabe cómo se hizo.

Solo sabe que si pide de esa forma, va a recibir lo que necesita.

Las respuestas tienen significado

En REST, las respuestas no son solo datos. Son decisiones estructuradas.

Cada respuesta incluye:

1. Un código de estado

Que dice qué pasó:

200 OK: Todo bien, aquí está lo que pediste
201 Created: Se creó algo nuevo
404 Not Found: No encontré lo que pediste
400 Bad Request: Tu petición está mal formada
500 Internal Server Error: Algo falló de mi lado

Estos son solo algunos de los códigos más comunes. Los códigos de estado HTTP son estándar, pero cada tipo de servidor puede manejar y devolver errores de forma ligeramente diferente. Puedes ver la lista completa de códigos de estado HTTP en la documentación de MDN.

2. Un cuerpo de respuesta

Que contiene la información:

{
  "id": 8,
  "nombre": "Ginny Weasley",
  "casa": "Gryffindor",
  "poder": 83
}

3. Headers (opcional)

Que dan contexto adicional:

Content-Type: application/json
Cache-Control: max-age=3600

Por ejemplo:

Content-Type: application/json indica que la respuesta está en formato JSON
Cache-Control: max-age=3600 indica que la respuesta puede guardarse en caché por 1 hora

Todo eso junto forma una respuesta completa. No es solo "aquí están los datos". Es "esto es lo que pasó, esto es lo que encontré, y así deberías interpretarlo".

Por qué REST reduce la confusión

Porque cuando todos siguen las mismas reglas:

Las peticiones son predecibles
Las respuestas tienen estructura
Los errores tienen significado
No tienes que adivinar cómo funciona cada API

Sin REST (o sin algún estilo similar), cada API sería diferente:

Unos usarían POST para todo
Otros inventarían sus propios códigos de error
Otros mezclarían acciones y recursos sin criterio

REST no es perfecto. Pero es un acuerdo que funciona.

Y cuando lo entiendes, dejas de ver las APIs como algo mágico y empiezas a verlas como lo que son: conversaciones con reglas claras.

Lo que aprendiste

REST es un estilo de comunicación, no una tecnología.
Las peticiones expresan intención a través de verbos HTTP.
Los recursos representan qué, no cómo.
El servidor interpreta la petición y decide qué responder.
Las respuestas tienen significado, no solo datos.
REST reduce el caos al establecer reglas claras para la conversación.
Entender REST no es memorizar verbos. Es entender por qué las APIs se diseñan de cierta forma. Y esa claridad es lo que te permite construir mejor, debuggear más rápido, y diseñar con más confianza.

Qué sigue

Ya entiendes qué es REST y cómo organiza la conversación entre quien pide y quien responde.

En el siguiente artículo vamos a ver cómo se implementa esto en la nube usando Amazon API Gateway.

Vas a entender cómo API Gateway actúa como la puerta de entrada a tu backend, cómo recibe peticiones REST, y cómo las conecta con tu lógica (ya sea en Lambda, en un servidor HTTP, o en otros servicios de AWS).

Ya sabes cómo funciona la conversación. Ahora es momento de ver cómo se despliega en producción.

A dónde va una petición cuando la envías (y qué pasa en el camino)

Hazel Saenz — Tue, 17 Feb 2026 14:35:30 +0000

Una explicación simple del viaje completo: desde que tu app pide algo hasta que recibe respuesta.

Ya sabes que las aplicaciones se comunican haciendo peticiones.

Tocas un botón. ➡️ La app pide algo. ➡️ Algo responde.

Pero entre ese "pedir" y ese "responder" hay un viaje completo. Y casi nunca se explica.

La mayoría de las veces, cuando aprendes sobre APIs, te dicen:

"La app hace una petición"
"El servidor responde"

Y listo.

Como si todo pasara instantáneamente. Como si no hubiera nada en el medio. Pero sí lo hay.

Y entender ese recorrido es lo que te ayuda a dejar de ver las APIs como algo abstracto y empezar a verlas como lo que son: conversaciones con pasos claros. Este artículo es ese mapa.

En el artículo anterior vimos que las aplicaciones no guardan todo localmente.

Cuando necesitan algo, preguntan, hacen una petición y esperan una respuesta.

Eso es una API: el acuerdo que define cómo se hace esa conversación. Pero quedó una pregunta sin responder:

👉 ¿Qué pasa entre el momento en que la app envía la petición y el momento en que recibe la respuesta?

Eso es lo que vamos a ver ahora.

Una petición sale de la app

Imagina que abres una app de Harry Potter y buscas información sobre "Ginny Weasley". (Y sí, si me conoces sabes que soy fan de Harry Potter, así que este ejemplo me hace especialmente feliz 😊)

La app no tiene todos los datos de los personajes guardados en tu teléfono. Así que hace una petición:

GET /personajes?nombre=Ginny+Weasley

Esa petición es un mensaje, no es código que se ejecuta en otro lugar, no es un archivo que se envía, es simplemente información estructurada que dice:

Qué quiero: información de personajes
Sobre quién: Ginny Weasley
Cómo lo pido: usando el método GET

Ese mensaje sale de tu app. Y empieza su viaje.➡️ ✉️

El viaje a través de la red

Tu petición no llega directamente al servidor, pasa por varios puntos en el camino:

Sale de tu dispositivo (tu teléfono, tu computadora)
Pasa por tu red local (tu WiFi o datos móviles)
Viaja por internet (a través de routers, cables, infraestructura)
Llega al servidor que tiene la información

Cada uno de esos pasos toma tiempo, a veces milisegundos y a veces segundos; por eso a veces una app carga rápido y otras veces tarda, no siempre es culpa de la app. A veces es el camino.

👉 Prueba este ejemplo interactivo para ver en acción cómo funciona una petición a una API de Harry Potter. Puedes ver el código de la demo en GitHub para entender cómo está construida.

El servidor recibe la petición

Cuando la petición llega al servidor, no se ejecuta automáticamente.

El servidor la recibe y la evalúa.

Piensa en el servidor como un portero que revisa cada mensaje que llega:

¿Esta petición está bien formada?
¿Tiene permiso para pedir esto?
¿Entiendo lo que está pidiendo?

Si algo falla en esta etapa, el servidor responde con un error.

Por ejemplo:

Si pediste algo que no existe: 404 Not Found
Si no tienes permiso: 403 Forbidden
Si la petición está mal hecha: 400 Bad Request

Pero si todo está bien, el servidor pasa a la siguiente etapa.

El proceso de decisión

Aquí es donde pasa la magia. El servidor no solo devuelve información, decide qué devolver.

Siguiendo el ejemplo de la app de Harry Potter:

El servidor recibe: GET /personajes?nombre=Ginny+Weasley
Busca en su base de datos información sobre "Ginny Weasley"
Recopila todos los datos del personaje (casa, varita, patronus, etc.)
Puede que incluya información relacionada (amigos, hechizos favoritos)
Procesa esa información
La estructura en el formato acordado (generalmente JSON)

Todo eso pasa en el backend.

La app que hizo la petición no sabe cómo funciona ese proceso.
No sabe si el servidor usa una base de datos SQL o NoSQL.
No sabe cómo funciona el algoritmo de recomendación.
No sabe si está en un servidor en California o en Singapur.

Solo sabe que si pide de cierta forma, va a recibir lo que necesita.

Esa es la belleza de las APIs: separan el "qué" del "cómo".

La respuesta regresa

Una vez que el servidor termina de procesar, construye una respuesta:

{
  "id": 8,
  "nombre": "Ginny Weasley",
  "casa": "Gryffindor",
  "poder": 83,
  "hechizo": "Reducto",
  "defensa": 77,
  "imagen": "🧙‍♀️"
}

Esa respuesta hace el viaje de regreso:

Sale del servidor
Viaja por internet
Pasa por tu red local
Llega a tu dispositivo
Tu app la recibe

El mismo camino, pero en reversa.

Cómo reacciona la app

Cuando la app recibe la respuesta, reacciona, no decide, no procesa lógica compleja, solo toma lo que recibió y lo muestra.

En este caso:

Muestra la foto del personaje
Muestra su casa y escudo de Gryffindor
Muestra información sobre su hechizo
Muestra información de defensa

Si la respuesta hubiera sido un error, la app mostraría un mensaje de error.

La app depende completamente de lo que el servidor responda.

Por eso cuando una API falla, la app no puede hacer nada, no puede inventar personajes, no puede adivinar información, solo puede mostrar que algo salió mal.

Por qué importa entender este flujo

Porque cuando entiendes que una petición es un viaje, no un evento instantáneo, empiezas a ver por qué:

Las apps a veces tardan en cargar (el viaje puede ser largo)
Los errores no siempre son culpa de la app (pueden pasar en cualquier punto del camino)
El backend tiene que ser confiable (es el que decide qué responder)
Las APIs bien diseñadas importan (hacen que todo este proceso sea predecible)

No es magia.n Es un proceso con pasos claros.

Y cuando algo falla, saber dónde buscar hace toda la diferencia.

Lo que aprendiste

Una petición no es un solo paso, es un viaje completo:

La app envía un mensaje
Ese mensaje viaja por la red
El servidor lo recibe y evalúa
El servidor decide qué responder
La respuesta regresa por el mismo camino
La app reacciona a lo que recibió

Las aplicaciones dependen de las respuestas.

Los servidores deciden.

Las APIs definen las reglas de esa conversación.

Entender este flujo te da claridad, y esa claridad es lo que te permite construir mejor, debuggear más rápido, y diseñar con más confianza.

Qué sigue

En el siguiente artículo vamos a dar el siguiente paso: construiremos nuestra primera API REST.

Vas a ver cómo crear un servidor que reciba peticiones, procese información y devuelva respuestas.

Ya entiendes el viaje completo de una petición.

Ahora es momento de construir el destino.

AWS Valentine’s LATAM: cuando el amor también se despliega en la nube

Hazel Saenz — Thu, 12 Feb 2026 01:22:37 +0000

Una colección de frases dev-amor inspiradas en AWS, creadas desde LATAM para celebrar San Valentín con humor, ternura y comunidad.

San Valentín no siempre se trata de flores o chocolates. A veces se trata de cómo explicamos lo que sentimos, usando el lenguaje que mejor conocemos.

En nuestro caso: el lenguaje de los devs.

El origen de esta idea

Hace unos días vi una serie de tarjetas de San Valentín creadas por Brooke Jamieson para la comunidad de AWS.
Eran divertidas, simples y muy nerd… y me hicieron sonreír.

Pero sobre todo, me hicieron pensar:

¿Cómo se vería esto si lo contáramos desde LATAM?

Con nuestro humor. Nuestra cercanía. Nuestra forma intensa, caótica y honesta de vivir tanto el código como las relaciones.

Así nació AWS Valentine’s LATAM.

No como una traducción. Sino como una reinterpretación con identidad propia.

Dev-amor, pero con acento latino

Estas frases no están pensadas solo para ingenieras o ingenieros.
Están pensadas para cualquiera que haya:

deployado con miedo, celebrado que “ya funciona”, sufrido un outage o encontrado refugio en alguien que se queda cuando todo falla.

Eres mi región primaria

(Amazon Route 53 / Multi-Region)
Porque mi tráfico siempre apunta a ti. Eres mi región primaria (y no hago failover).

Eres la respuesta correcta

(Amazon API Gateway)

Eres la respuesta correcta, a todas mis peticiones.

No importa la distancia

(Amazon CloudFront)

No importa la distancia, igual llegas a mi edge.

Funciona por fe

(AWS Lambda)

Funciona por fe, y porque tú estás ahí.

Nuestro amor sobrevivió

(Amazon CloudWatch / Outage vibes)

Se cayó todo… menos nosotros. Nuestro amor sobrevivió al outage.

No me asustas, me acompañas

(Kiro – agentic AI, spec-driven dev)

No me asustas, me acompañas. Contigo todo empieza como idea y termina en algo real.

Guardado para siempre

(Amazon S3)

Aunque el mundo se mueva, lo nuestro no se pierde.

¿Por qué compartir esto?

Porque la tecnología también puede ser suave.
Porque no todo contenido técnico tiene que ser rígido.
Porque las comunidades se construyen con conocimiento, sí…
pero también con emoción, cercanía y humanidad.

Y porque en LATAM: amamos intenso, incluso cuando hablamos de la nube.

Para la comunidad

Si alguna de estas frases te hizo sonreír, si te recordó a alguien, o si te dan ganas de compartirla en tu equipo, comunidad o meetup: misión cumplida.

Gracias a la comunidad de AWS por inspirar, y a personas como Brooke por recordarnos que el tech también puede ser divertido.

Feliz San Valentín, desde LATAM, con amor y con cloud.

Qué pasa realmente cuando una app pide algo

Hazel Saenz — Fri, 06 Feb 2026 01:40:19 +0000

Una explicación simple para entender cómo se comunican las aplicaciones (y por qué a eso le llamamos API).

Abres una app. ➡️ Tocas un botón. ➡️ Algo carga.
No piensas mucho en eso. Solo esperas que funcione.
Pero detrás de ese gesto tan simple, hay una conversación ocurriendo.

Tu app de música no guarda millones de canciones en tu teléfono.
Tu app del clima no tiene sensores en cada ciudad.
Tu app de delivery no cocina la comida.

Lo que hacen es pedirle esa información a otros sistemas.

Esa conversación casi nunca se explica.

Si alguna vez viste que una app “pide algo” y otra le responde, y sentiste que entendías lo suficiente para seguir, pero no tanto como para explicarlo… este artículo es para ti.

No es magia. Es una conversación.

Cuando una aplicación necesita algo que no tiene —datos, resultados, información— no entra al sistema del otro lado como si fuera su casa.

No toca lo que no le corresponde.
No improvisa.
No adivina.

Hace algo más simple:

👉 pregunta. Y espera una respuesta.

Imagina que abres Spotify y buscas "Bad Bunny".
La app no tiene todas las canciones guardadas en tu teléfono.
Hace una petición: "Dame las canciones de Bad Bunny".
El servidor responde con la lista.

La app hace una petición clara.
El sistema del otro lado responde solo lo que prometió responder.

Ni más. Ni menos. No hay magia. Hay reglas.

Antes de ponerle nombre, mira lo que pasa

Una app necesita información.
No sabe cómo está construido el sistema del otro lado.
No le importa si usa Java, Python o cualquier otra cosa.

Solo sabe dos cosas: qué puede pedir y qué va a recibir a cambio.

Volviendo al ejemplo:

Petición:
GET /buscar?artista=bad-bunny

Respuesta:
{
  "artista": "Bad Bunny",
  "canciones": ["DÁKITI", "Tití Me Preguntó", "Callaíta", ...]
}

La app no sabe dónde están guardadas esas canciones.
No sabe si el servidor usa una base de datos SQL o NoSQL.
Solo sabe que si pide de esa forma, va a recibir lo que necesita.

Ese intercambio existe aunque casi nunca lo nombremos. Está ahí cada vez que una app pide algo y otra responde.

Eso tiene un nombre: API

A esa forma de comunicarse se le llama API.

No es el sistema completo.
No es la base de datos.
No es la lógica interna.

Es el acuerdo que define cómo dos partes se hablan sin conocerse por dentro.
Y aquí es donde empiezan muchos de los malentendidos.

Mito #1: “Una API es el backend”

No. El backend es todo lo que pasa detrás:lógica, datos, procesos, decisiones.

La API es la puerta, no la casa.

Es lo único que se muestra hacia afuera.
Lo que marca el límite entre lo que se puede usar y lo que no.

Cuando estas dos cosas se confunden, suele pasar que:

se exponen cosas que no deberían
se rompen acuerdos sin darse cuenta
se diseña pensando en el sistema, no en quien lo usa

Mito #2: “Una API es solo una dirección”

Muchas veces se piensa que una API es solo “el lugar al que haces la petición”.

Como si todo se redujera a mandar algo y esperar respuesta.
Pero una dirección por sí sola no explica nada.

Puede decirte a dónde ir, pero no te dice:

qué puedes pedir
cómo hacerlo
ni qué significa lo que recibes de vuelta

Por ejemplo, /buscar?artista=bad-bunny es una dirección.
Pero sin saber que:

debes usar el método GET
el parámetro se llama artista
la respuesta será un JSON con canciones

...esa dirección no te sirve de mucho.

Esa dirección —a la que luego llamamos endpoint—, el punto específico donde se hace la petición, solo cobra sentido cuando existen reglas claras alrededor.

Una API no es solo el punto de entrada. Es el acuerdo completo que le da significado a la conversación.

Entonces… ¿qué hacen realmente las APIs?

Las APIs reducen el caos. Permiten que sistemas distintos:

trabajen juntos
sin depender uno del otro
sin romperse cada vez que algo cambia

Por ejemplo:

Spotify puede mostrar canciones de Bad Bunny sin importar si:

el servidor de música está en AWS o en otro cloud provider
la base de datos cambió de MySQL a PostgreSQL
el equipo de backend reescribió todo en otro lenguaje

Mientras la API siga respondiendo de la misma forma, la app sigue funcionando.

Eso es lo que hace que puedas usar la misma app en tu teléfono durante años, aunque todo detrás haya cambiado varias veces.

Cuando una API está bien diseñada, casi no se nota. Cuando no lo está, se siente en cada error, en cada confusión, en cada workaround.

Por qué importa entender esto desde el inicio

Porque cuando no tienes claro qué es una API, todo parece más complejo de lo que es.

No porque falte aprender más, sino porque muchas veces nadie explicó bien el contexto.

Este es solo el comienzo

Este artículo no es para memorizar definiciones.
Es para empezar a ver algo que ya estaba ocurriendo.

En los siguientes artículos vamos a mirar con más detalle:

qué pasa realmente cuando una app hace una petición
por qué REST no es el problema
por qué muchas APIs fallan sin estar “rotas”
y cómo diseñarlas pensando en personas, no solo en sistemas

Si alguna vez sentiste que las APIs eran algo que usabas, pero que nadie te había explicado con claridad… A veces no falta aprender más, sino que alguien explique mejor.

DEV Community: Hazel Saenz

Multi-step workflows que sobreviven fallos

El replay model por dentro

Anatomía de un checkpoint

Consideraciones sobre el tamaño de los datos

Rompiendo cosas a propósito — Escenario 1: Fallo transitorio

Simulando un fallo de red en el resize

Qué pasa cuando lo ejecutas

Estrategias de reintento

Exponential backoff: por qué importa

Aplicando retry strategy al step de watermark

Qué errores reintentar y cuáles no

Rompiendo cosas a propósito — Escenario 2: Fallo permanente

Simulando un archivo corrupto

Qué está pasando aquí

El patrón de compensación

Errores fuera de los steps

La regla: todo lo que puede fallar va dentro de un step

¿Qué es idempotencia?

La analogía del elevador

En software

Cómo hacer idempotente lo que no lo es

Idempotencia en Durable Functions: la regla que nadie te dice

El ejemplo del procesamiento de imágenes

Checklist de idempotencia para tus steps

AT_MOST_ONCE_PER_RETRY: la red de seguridad del SDK

Rompiendo cosas a propósito — Escenario 3: Timeout de la función

Pero espera... ¿y el durableConfig.executionTimeout?

Monitoreando fallos en la consola

Tips para debugging efectivo

Patrones de resiliencia

1. Retry con backoff exponencial

2. Compensación

3. Circuit breaker manual

4. Dead letter queue para workflows irrecuperables

Lo que aprendiste

Qué sigue

Cómo crear un agente de IA desde cero. Open source, local y gratis.

¿Qué es un agente de IA?

Por qué open source importa (de verdad)

El stack: Python + Strands Agents + Ollama

Ollama: modelos de IA en tu laptop

Instalación

Descargar y correr un modelo

Capa 1: Un agente que solo habla

Capa 2: Dale herramientas — la biblioteca de canciones

Capa 3: Más herramientas, más inteligencia

Capa 4: Memoria — el DJ te conoce

De tu laptop a la nube (en una línea)

Lo que aprendiste

Qué sigue

Escala Inteligente con Microservicios Serverless

¿Realmente necesitas microservicios?

Señales reales vs. falsas alarmas

No es binario — hay un espectro

Serverless cambia las reglas

Los 3 patrones clave

Patrón 1: Comunicación desacoplada — eventos, no llamadas directas

Patrón 2: Cada servicio, su data

Patrón 3: Observabilidad desde el día 1

El framework de decisión

Lo que quiero que te lleves

Qué sigue

Recursos

AWS Lambda Durable Functions + IA: el combo que no sabías que necesitabas

Espera... ¿qué es Kiro?

¿Qué es un Kiro Power?

El Lambda Durable Functions Power

Instalando el Power

Prerequisitos

Creando tu primer proyecto

Inicializar el proyecto

Instalar dependencias

Estructura del proyecto

Tu primera Durable Function (generada por el Power)

Qué está pasando aquí

El Kiro Power y la regla de oro del Replay Model

Testeando localmente

Haciendo deploy con CDK

Lo que importa aquí

Pero espera... ¿y el `durableConfig.executionTimeout`?