Patrones
La gramática: cómo se combinan las piezas. Cada ficha dice cuándo usar el patrón, cuándo no, y qué te va a morder en producción.
18 de 18 escritos
Comunicación
- Claim-checkClaim-checkGuardar el contenido pesado en S3 y hacer viajar por el sistema de mensajería solo una referencia, para que los límites de tamaño de los mensajes dejen de decidir tu arquitectura.
- Cola punto a puntoPoint-to-point channel / competing consumersDesacoplar a quien pide el trabajo de quien lo hace con una única cola, de forma que el pico se absorba, el trabajo se reparta y añadir capacidad sea añadir consumidores.
- Fan-outFan-out / publish-subscribeUn productor emite un hecho una sola vez y varios consumidores independientes reaccionan a él en paralelo, sin que el productor sepa cuántos son ni qué hacen.
- Pub/sub con EventBridgeContent-based routingPublicar eventos en un bus donde cada consumidor declara con un patrón qué le interesa, de modo que el productor no conozca ni un solo destino y añadir consumidores no toque nada.
Fiabilidad
- Circuit breakerCircuit breakerDejar de llamar a un servicio que lleva un rato fallando, para convertir una espera cara en un error barato y no arrastrar a tu propio servicio con la caída del vecino.
- DLQ y redriveDead-letter queueApartar los mensajes que fallan una y otra vez para que dejen de bloquear al consumidor y de quemar dinero, y poder investigarlos y reinyectarlos cuando el bug esté arreglado.
- Idempotencia en consumidoresIdempotent consumerProcesar el mismo mensaje dos veces produce exactamente el mismo resultado que procesarlo una, de modo que los duplicados —que son inevitables— dejan de importar.
- Outbox con DynamoDB StreamsTransactional outboxGuardar el dato y el evento que lo anuncia en la misma transacción, de modo que sea imposible que uno exista sin el otro, y publicar después leyendo del cambio ya escrito.
- Retry con backoff y jitterExponential backoff with jitterVolver a intentar lo que falló de forma transitoria, esperando cada vez más y con un componente aleatorio, para no convertir un incidente pequeño en una avalancha sincronizada contra un servicio que se estaba recuperando.
- Saga orquestada con Step FunctionsOrchestrated sagaCoordinar una operación que toca varios servicios sin transacción distribuida, ejecutando los pasos en orden y deshaciéndolos con compensaciones explícitas cuando uno falla.
- Saga por coreografíaChoreographed sagaCoordinar una operación que toca varios servicios sin director: cada uno reacciona al evento del anterior y publica el suyo, y las compensaciones son también eventos a los que alguien reacciona.
Datos
- Single-table designSingle-table designGuardar varios tipos de entidad en una misma tabla de DynamoDB con claves genéricas, de modo que una sola consulta devuelva todo lo que una pantalla necesita en vez de cinco.
- Write shardingWrite shardingRepartir las escrituras de una clave muy caliente entre varias claves sintéticas, para dejar de chocar contra el techo de una sola partición de DynamoDB.
Escala
- Batching y fallo parcialPartial batch responseProcesar mensajes en lotes para pagar menos invocaciones, sin que un solo registro venenoso arrastre a los otros nueve en cada reintento.
- Cold startCold start / function init latencyEntender qué tarda de verdad cuando Lambda arranca un entorno nuevo, cuánto de eso puedes acortar tú, y decidir con criterio si merece la pena pagar por evitarlo.
- Concurrencia reservada como aislamientoReserved concurrencyRepartir el bote de concurrencia de la cuenta para que ninguna función pueda quedarse con todo, y de paso poner un tope a las que hablan con dependencias que no escalan como Lambda.
Frontera
- Presigned URLsPresigned URLsDar al cliente una URL firmada y con caducidad para que suba o descargue directamente de S3, sin que el archivo atraviese tu API ni tus funciones.
- Throttling y rate limitingRate limitingRechazar en la puerta el tráfico que no cabe, para que el rechazo sea barato y ocurra donde tú lo decides en lugar de caro y donde lo decida el primer servicio que se rompa.