Tot el que hem muntat al mòdul és coreografia: cada component reacciona al que veu i ningú no té la foto completa. Funciona esplèndidament per a fets independents —enviar un correu, carregar analítica, generar una miniatura— i es trenca tan bon punt els passos depenen els uns dels altres i cal desfer el que s'ha fet si alguna cosa falla a mig camí.

El procés de comanda de MercadoFresco és exactament aquest cas: cobrar la targeta, reservar l'estoc, demanar al magatzem que prepari la caixa —que triga entre dos minuts i una hora i la confirma una persona amb un lector de codis—, assignar repartiment i confirmar al client. Si el peix arriba en mal estat i el magatzem no pot preparar la comanda, cal tornar el cobrament i alliberar l'estoc. Amb esdeveniments solts ningú no sap en quin punt era el procés ni què toca compensar; l'única manera és una taula d'estat escrita a mà, un procés que la vigili i un munt de casos rars que no es proven mai.

AWS Step Functions és l'orquestrador sense servidor d'AWS. Defineixes el procés com una màquina d'estats en JSON, i el servei s'encarrega d'executar cada pas, desar l'estat entre passos, reintentar amb retrocés exponencial, capturar errors, esperar hores o dies si cal, i deixar un historial complet de cada execució. Aquí el Luis construeix mercadofresco-procesar-pedido amb el seu camí de compensació complet.

Avís de cost. Els fluxos estàndard costen 0,025 USD per 1.000 transicions d'estat; els exprés, per nombre d'execucions i per GB-segon. Un bucle mal dissenyat amb Wait curt pot generar centenars de milers de transicions en una nit. Al final tens la neteja. Dades fictícies.

1. Coreografia enfront d'orquestració
2. Fluxos estàndard i fluxos exprés
3. Amazon States Language: l'estructura
4. Els vuit tipus d'estat
5. Flux de dades entre estats
6. Integracions i patrons de servei
7. El testimoni de retorn per al pas humà del magatzem
8. Gestió d'errors: Retry i Catch
9. El patró saga: compensar el que ja s'ha fet
10. mercadofresco-procesar-pedido completa
11. Map distribuït per al volum del divendres
12. Desplegament i arrencada des d'EventBridge
13. Observabilitat: depurar una execució fallida
14. Workflow Studio i cost
15. Errors habituals i consells
16. Exercicis
17. Conclusió

Tria coreografia quan els consumidors són independents, l'ordre no importa, cadascun pot fallar pel seu compte sense afectar els altres i vols poder afegir interessats sense tocar res. És el que hem fet amb PedidoConfirmado: el correu, l'analítica i màrqueting no es coneixen ni els cal.

Tria orquestració quan hi ha un procés de negoci amb nom, els seus passos depenen del resultat dels anteriors, hi ha decisions condicionals, hi ha esperes llargues o intervenció humana, i —sobretot— cal compensar el que s'ha fet si alguna cosa falla a mig camí. Cobrar una targeta i no poder servir la comanda no s'arregla amb reintents: s'arregla tornant els diners, i algú ha de saber que cal fer-ho.

MercadoFresco acaba amb totes dues: bus-mercadofresco reparteix els fets, i una de les seves regles arrenca la màquina d'estats que governa el procés de comanda. No competeixen; es complementen.

La fila decisiva és la semàntica. Un flux estàndard garanteix que cada pas s'executa exactament una vegada: si el servei té un problema intern, reprèn des d'on era sense repetir. Un flux exprés pot reexecutar un pas, així que tots els seus passos han de ser idempotents.

Per a MercadoFresco: mercadofresco-procesar-pedido és estàndard, perquè cobra targetes, dura fins a una hora i no es pot permetre repetir un cobrament. En canvi, la validació de la cistella abans de pagar —comprovar estoc, recalcular preus, aplicar cupons, tot en menys d'un segon i sense efectes externs— és una candidata perfecta per a un flux exprés (mercadofresco-validar-carrito).

Una màquina d'estats és un objecte JSON amb tres claus de nivell superior.

• StartAt: el nom del primer estat. Obligatori.
• States: un objecte on cada clau és el nom de l'estat. Els noms són identificadors únics i apareixen tal qual a la consola i a l'historial, així que convé que siguin descriptius i estables: canviar-los trenca els enllaços de les alarmes i confon l'historial.
• Cada estat té un Type i, tret dels terminals, un Next o "End": true.

No hi ha bucles explícits ni variables globals en el sentit clàssic: el «bucle» es fa amb un Choice que torna a un estat anterior, i l'«estat» és el JSON que viatja d'un estat al següent. Aquesta restricció és deliberada i fa que el flux sigui inspeccionable.

Task — fa feina. És l'únic que crida alguna cosa externa.

Choice — bifurca segons el contingut. No fa feina, decideix.

Els comparadors cobreixen cadenes, nombres, booleans, marques de temps i presència (IsPresent, IsNull), amb variants Path per comparar dos camps entre si. Default no és opcional a la pràctica: si cap condició no encaixa i no hi ha Default, l'execució falla amb States.NoChoiceMatched.

Parallel — executa diverses branques alhora amb la mateixa entrada, i retorna un array amb els resultats en l'ordre de les branques.

Compte: si una branca falla, tot el Parallel falla i la resta es cancel·len. Si vols tolerància, posa Catch dins de cada branca.

Map — executa la mateixa sublògica per a cada element d'un array. És la diferència amb Parallel: mateixes branques diferents vs. mateixa branca, dades diferents.

$$ és l'objecte de context, que dona accés a metadades de l'execució: $$.Map.Item.Value és l'element actual, $$.Execution.Name el nom de l'execució, $$.Task.Token el testimoni de retorn.

Wait — espera. Per segons fixos (Seconds), fins a una marca de temps (Timestamp), o amb el valor pres de l'entrada (SecondsPath, TimestampPath).

Un Wait de tres dies no consumeix res: Step Functions no manté cap procés esperant i no es cobren transicions mentre espera. És una de les diferències més pràctiques respecte a implementar-ho a mà.

Pass — no fa feina; transforma o injecta dades. Insubstituïble per depurar i per normalitzar formes del JSON entre passos.

Succeed i Fail — acaben l'execució. Fail accepta Error i Cause, que són el que apareixerà a l'historial i a la mètrica ExecutionsFailed; posa-hi textos útils.

Aquesta és la part que més costa, i mereix traçar-se pas a pas. Cada estat Task aplica cinc filtres en aquest ordre exacte:

Els camps acabats en .$ prenen el seu valor d'una ruta JSONPath en lloc d'un literal. És la regla que cal aprendre: "FunctionName": "mercadofresco-cobrar-pago" és un literal; "Payload.$": "$.pedido" és una referència.

Exemple traçat. L'entrada de l'estat CobrarPago és:

Amb l'estat definit més amunt:

1. InputPath no hi és, així que es pren tot ($).
2. Parameters construeix {"FunctionName": "mercadofresco-cobrar-pago", "Payload": {"pedido_id": "PED-2026-084417", "importe_eur": 48.20, "cliente_id": "CLI-30912"}}. Només això arriba a Lambda.
3. Lambda respon, i la integració lambda:invoke embolcalla la resposta: {"ExecutedVersion": "$LATEST", "Payload": {"referencia": "PAY-77321", "estado": "capturado"}, "StatusCode": 200}.
4. ResultSelector {"referencia_cobro.$": "$.Payload.referencia"} retalla a {"referencia_cobro": "PAY-77321"}, llençant el soroll de la integració.
5. ResultPath "$.cobro" insereix aquest objecte a l'entrada original sota la clau cobro.
6. OutputPath no hi és, així que surt tot.

Sortida final, que és l'entrada de ReservarStock:

Tres valors especials de ResultPath que cal conèixer:

L'error clàssic és deixar ResultPath per defecte en un Task intermedi: la resposta de Lambda esclafa la comanda sencera i l'estat següent no troba $.pedido. Regla de MercadoFresco: en tot Task intermedi, ResultPath explícit.

Step Functions crida altres serveis de dues maneres. Les integracions optimitzades tenen ARN propi (arn:aws:states:::lambda:invoke, :::dynamodb:putItem, :::sns:publish, :::sqs:sendMessage, :::ecs:runTask) i afegeixen comoditats. Les integracions de l'SDK cobreixen més de 200 serveis i 9.000 accions amb la forma arn:aws:states:::aws-sdk:<servei>:<accio>, per exemple arn:aws:states:::aws-sdk:rds:describeDBClusters. Si alguna cosa es pot fer amb l'SDK, es pot fer sense escriure una Lambda.

I hi ha tres patrons d'integració que canvien completament el comportament del Task:

La diferència entre resposta i .sync és enorme i sovint es malinterpreta. ecs:runTask retorna tan bon punt ECS accepta la petició —la tasca pot trigar deu minuts més—; ecs:runTask.sync no continua fins que la tasca acaba, i falla si la tasca falla. Sense .sync hauries de muntar un bucle de sondeig amb Wait i Choice, que és exactament el que el patró t'estalvia.

La preparació al magatzem no és una crida a una API: és una persona que agafa una caixa, l'omple i passa un lector de codis. Pot trigar dos minuts o una hora, i de vegades respon «no puc».

.waitForTaskToken està fet per a això. Step Functions genera un testimoni, el fica a la càrrega que envia a la destinació i atura l'estat indefinidament (fins a HeartbeatSeconds o TimeoutSeconds). L'execució no consumeix res mentre espera. Quan el sistema del magatzem acaba, crida SendTaskSuccess o SendTaskFailure amb aquest testimoni, i la màquina continua.

El costat del magatzem, que és una aplicació normal:

HeartbeatSeconds: 600 és la protecció contra l'operari que se'n va a dinar amb la caixa a mig fer: si no arriba cap batec en 10 minuts, l'estat falla amb States.Heartbeat i el procés pot reaccionar molt abans del TimeoutSeconds d'una hora. I error="AlmacenNoPuedePreparar" no és decoratiu: és el valor que es compara a ErrorEquals per triar el camí de compensació.

Dos advertiments. El testimoni caduca amb l'execució: si la màquina s'atura, SendTaskSuccess retornarà TaskTimedOut. I cal desar el testimoni en algun lloc persistent (al mateix missatge de la cua, com aquí, o a DynamoDB), perquè és l'única cosa que permet reprendre.

Retry reintenta el mateix estat. Catch abandona l'estat i salta a un altre. S'avaluen en aquest ordre: primer s'esgoten els reintents, i només aleshores actua el Catch.

JitterStrategy: "FULL" hauria de ser el teu valor per defecte. Sense ell, si la passarel·la de pagament cau 30 segons, les 450 execucions en curs reintenten exactament en el mateix instant i la tomben altre cop just quan s'estava recuperant. És la tempesta de reintents, que veurem a fons a 07-05.

L'ordre dels blocs importa. El primer que encaixi guanya, així que els errors específics van abans que els genèrics. A l'exemple, TarjetaRechazada amb MaxAttempts: 0 desactiva explícitament el reintent per a un error que no s'arregla reintentant: la targeta continuarà rebutjada. Distingir errors transitoris de permanents és la mateixa disciplina de 07-01, ara declarativa.

Catch funciona igual, però en lloc de reintentar salta:

ResultPath al Catch és crític. Amb "$.error", l'estat de destinació rep l'entrada original més l'objecte {"Error": "...", "Cause": "..."} sota error. Sense ell (valor per defecte $), l'error substitueix tota l'entrada i l'estat de compensació es queda sense saber quina comanda compensar ni quina referència de cobrament tornar. És la fallada més frustrant de depurar a Step Functions.

Errors predefinits que convé conèixer: States.Timeout, States.TaskFailed, States.Permissions, States.ResultPathMatchFailed, States.NoChoiceMatched, States.Heartbeat, States.DataLimitExceeded (la càrrega entre estats ha superat els 256 KB).

No hi ha transaccions distribuïdes entre una passarel·la de pagament, Aurora, DynamoDB i l'ERP d'un soci. L'alternativa realista és la saga: una seqüència de passos on cadascun té una compensació que desfà el seu efecte, i si alguna cosa falla s'executen les compensacions dels passos ja completats, en ordre invers.

La compensació no és un rollback: és una acció de negoci nova i visible. Una devolució apareix a l'extracte del client; els diners van estar retinguts. Per això les sagues es dissenyen per minimitzar el temps entre el pas arriscat i la seva possible compensació, i per això convé ordenar els passos de més a menys reversible quan es pugui, deixant els irreversibles per al final.

Fixa't en RevisionManual. Les compensacions també fallen, i quan falla una devolució hi ha diners d'un client retinguts sense comanda: això no pot acabar en un Fail silenciós. Aquest estat publica a alertas-mercadofresco i escriu en una cua que la Marta revisa. Tota saga necessita el seu camí de «això ja és per a un humà».

Detalls que no són casuals. ResultPath: null a les compensacions i a la notificació: el seu resultat no aporta res i així no s'embruta l'estat. Més reintents a DevolverCobro (6) que a la resta: fallar una devolució és molt més car que fallar qualsevol altra cosa. PedidoRechazado no passa per compensació, perquè si la targeta es va rebutjar no es va cobrar res. I States.JsonToString($) és una de les funcions intrínseques del llenguatge; n'hi ha més (States.Format, States.Array, States.ArrayPartition, States.MathRandom, States.UUID) que eviten haver d'escriure una Lambda només per transformar dades.

El Map en mode INLINE té dos límits: 40 iteracions concurrents i totes les dades a l'estat, subjectes al màxim de 256 KB. Per conciliar les 4.300 comandes d'un divendres contra els apunts de la passarel·la, o per processar un fitxer de 200.000 línies a S3, cal el mode DISTRIBUTED.

Les diferències amb el mode INLINE són substancials:

ToleratedFailurePercentage: 2 permet que fins a un 2 % dels apunts falli sense avortar la conciliació sencera —el típic quan el fitxer del banc porta línies rares— i ItemBatcher agrupa 25 elements per invocació de Lambda, dividint per 25 el nombre d'invocacions i el seu cost. Com que cada iteració és una execució filla, l'historial de la pare no s'omple amb 4.300 entrades, que és el que feia inservible la consola amb el mode INLINE.

El rol rol-mf-step-functions necessita permís per a cada acció que la màquina executa: lambda:InvokeFunction sobre les cinc funcions, sqs:SendMessage sobre la cua del magatzem, events:PutEvents sobre el bus, sns:Publish sobre el tema d'alertes, més xray:PutTraceSegments i els permisos d'escriptura al grup de registres. Un States.Permissions enmig d'una compensació és de les fallades més desagradables que hi ha: la comanda queda a mitges perquè l'orquestrador no podia cridar qui tocava.

L'arrencada la fa una regla de bus-mercadofresco:

Un truc molt recomanable: passar com a nom d'execució un valor derivat del pedido_id. Els noms d'execució han de ser únics en 90 dies, així que si el mateix esdeveniment arriba dues vegades, la segona execució falla amb ExecutionAlreadyExists en lloc de cobrar la targeta un altre cop. És idempotència de franc, i enllaça directament amb 07-05.

Step Functions desa l'historial complet de cada execució estàndard durant 90 dies: cada entrada d'estat, cada sortida, cada reintent, cada error. És la seva millor característica i no té equivalent en una orquestració escrita a mà.

Una execució fallida real. La Marta veu una execució en FAILED i recorre l'historial cap enrere:

1. ExecutionFailed amb Error: "PedidoNoPreparable" → va acabar a PedidoCompensado, així que la compensació va funcionar. Bon senyal: el client té els seus diners.
2. TaskStateExited de DevolverCobro i de LiberarStock → les dues compensacions es van executar.
3. TaskFailed a PrepararEnAlmacen amb Error: "States.Heartbeat" → no va ser un rebuig del magatzem, va ser falta de batec. El terminal va deixar d'enviar SendTaskHeartbeat.
4. TaskScheduled de PrepararEnAlmacen a les 18:47, TaskFailed a les 18:57 → exactament els 600 segons de HeartbeatSeconds.

Diagnòstic: no és un problema de negoci, és que el terminal del magatzem perd la connexió wifi a la cambra de fred i deixa d'enviar batecs. La correcció no és a la màquina d'estats —que es va comportar correctament— sinó al terminal, que ha de reintentar el batec, i a apujar HeartbeatSeconds a 900 per tolerar els talls coneguts. Sense l'historial, aquest diagnòstic hauria trigat dies.

Amb --tracing-configuration '{"enabled":true}', X-Ray (05-02) mostra el mapa de serveis de l'execució i on se'n va anar el temps: quant a la passarel·la, quant esperant el magatzem, quant a Aurora. I les mètriques de CloudWatch a vigilar són ExecutionsFailed, ExecutionsTimedOut, ExecutionsAborted i ExecutionTime, totes amb alarma cap a alertas-mercadofresco.

Un detall de configuració: "level": "ERROR" registra només els estats fallits. "ALL" registra tot i és utilíssim mentre desenvolupes, però en producció, amb 240.000 execucions al mes i includeExecutionData: true, el volum de CloudWatch Logs pot costar més que la mateixa màquina.

Workflow Studio és l'editor visual de la consola: arrossegues estats, configures integracions des de formularis i veus el JSON generar-se en temps real, amb validació al vol. És la millor manera d'aprendre el llenguatge i d'explorar les 9.000 accions de l'SDK, i també de dibuixar el primer esborrany d'un flux amb la Marta al davant. Per a producció, la definició viu al repositori i es desplega amb CloudFormation o CDK (mòdul 9): l'editor visual serveix per dissenyar i per llegir, no per ser la font de la veritat.

Cost. Els fluxos estàndard es cobren per transició d'estat: 4.000 de franc al mes i després 0,025 USD per 1.000. mercadofresco-procesar-pedido recorre uns 9 estats per comanda en el camí feliç.

La comparació estàndard/exprés és reveladora: el mateix procés en exprés costaria uns 3 USD en lloc de 54. Per què no fer servir exprés per a tot, doncs? Perquè el procés de comanda dura fins a una hora (el màxim d'exprés són 5 minuts), necessita waitForTaskToken asíncron, necessita semàntica d'exactament una vegada per no cobrar dues vegades, i necessita l'historial de 90 dies per a les reclamacions. Els 51 USD de diferència compren precisament això, i per a 240.000 comandes amb un import mitjà de 48 € és una fracció menyspreable de la facturació.

La regla pràctica: exprés per al que és curt, idempotent i d'alt volum; estàndard per al que és llarg, crític i s'ha de poder auditar.

Esborrar una màquina d'estats no cancel·la les execucions en curs: passen a ABORTED quan acabin els passos actuals, i les que esperen un testimoni queden òrfenes.

Deixar ResultPath per defecte en un Task intermedi. El resultat substitueix tota l'entrada i l'estat següent no troba les seves dades. Símptoma: States.Runtime amb «no s'ha pogut resoldre la ruta». Posa ResultPath explícit sempre, o null si el resultat no importa.

Oblidar ResultPath al Catch. L'estat de compensació rep només l'error i no sap quina comanda compensar ni quin cobrament tornar. És la fallada més frustrant d'aquesta lliçó.

Choice sense Default. Un cas no previst acaba en States.NoChoiceMatched i l'execució mor sense compensar res.

No distingir errors transitoris de permanents al Retry. Reintentar quatre vegades una TarjetaRechazada endarrereix la resposta al client i no arregla res. Declara MaxAttempts: 0 per als errors permanents, i posa'ls abans del bloc genèric.

Retry sense JitterStrategy: "FULL". Quan la dependència es recupera, totes les execucions reintenten alhora i la tornen a tombar.

Compensacions sense el seu propi Catch. Si la devolució falla i no hi ha camí a revisió manual, el client es queda sense comanda i sense diners, i ningú no se n'assabenta.

Passar càrregues grans entre estats. El límit és 256 KB. Un Map amb 5.000 elements peta amb States.DataLimitExceeded. Passa referències a S3, no continguts.

waitForTaskToken sense HeartbeatSeconds ni TimeoutSeconds. L'execució es queda esperant fins a l'any, ocupant una ranura i sense que ningú se n'adoni.

Fer servir exprés per a processos amb efectes no idempotents. La semàntica d'almenys una vegada significa que un cobrament es pot executar dues vegades.

Parallel sense Catch per branca. La fallada d'una branca cancel·la les altres, incloses les que ja anaven per la meitat.

Consell: anomena l'execució amb l'identificador de negoci. PED-2026-084417 com a nom d'execució dona idempotència de franc, i cercar a la consola passa d'impossible a immediat.

Consell: valida el flux de dades amb Pass abans d'escriure la lògica. Munta la màquina sencera amb estats Pass que retornen dades fictícies, comprova que el JSON arriba bé d'un extrem a l'altre, i només aleshores substitueix cada Pass pel seu Task.

Consell: "level": "ALL" en desenvolupament, "ERROR" en producció. El registre complet amb dades d'execució és caríssim a 240.000 execucions al mes.

Dissenya mercadofresco-procesar-devolucion per quan un client torna una comanda ja lliurada. Passos: (1) validar que la devolució és dins de termini (48 h); (2) generar l'etiqueta de recollida cridant l'API del transportista; (3) esperar que el transportista confirmi la recollida, que pot trigar fins a 3 dies; (4) quan arribi al magatzem, un operari inspecciona l'estat del producte i decideix acceptar, acceptar parcialment o rebutjar; (5) segons la decisió, tornar l'import total, parcial o cap; (6) reposar l'estoc només si es va acceptar.

Indica: (a) estàndard o exprés i per què; (b) quin tipus d'estat fas servir a cada pas; (c) com modeles els passos 3 i 4; (d) quin Retry i quin Catch poses al pas 5; (e) quines compensacions necessites i quines no.

Donat aquest estat i aquesta entrada, escriu la sortida exacta que rep l'estat següent.

Entrada: {"pedido": {"pedido_id": "PED-1", "cliente_id": "CLI-9", "importe_eur": 30.0}, "origen": "web"}. La Lambda retorna {"nivel_fidelidad": "oro", "email": "[email protected]", "telefono": "+34600000000"}.

Respon: (a) què rep exactament la Lambda; (b) la sortida completa de l'estat; (c) què passaria si es tragués ResultPath; (d) què passaria si OutputPath fos "$.cliente"; (e) per què InputPath no afecta on insereix ResultPath.

Per a cada cas, decideix i justifica en dues frases: (a) en confirmar una comanda cal avisar quatre equips independents; (b) l'alta d'un proveïdor requereix validar documents, aprovació de dues persones i alta a Aurora, amb termini de 10 dies; (c) cal redimensionar 8.000 fotos del catàleg cada nit; (d) en detectar StockBajo cal demanar al proveïdor, esperar confirmació i actualitzar la data prevista; (e) cal registrar cada canvi de preu a Redshift per a auditoria.

Solució 1

(a) Estàndard, sens dubte. El pas 3 pot durar 3 dies, molt per damunt dels 5 minuts d'exprés. A més hi ha diners pel mig i cal la semàntica d'exactament una vegada i l'historial de 90 dies per a les reclamacions.

(b) i (c) Els estats. (1) Choice comparant $$.Execution.StartTime amb la data de lliurament; si és fora de termini, Fail amb Error: "FueraDePlazoDevolucion" sense compensar res, perquè encara no s'ha fet res. (2) Task amb Retry i JitterStrategy: FULL cap a l'API del transportista. (3) Task amb .waitForTaskToken i TimeoutSeconds: 259200 (3 dies): el webhook del transportista crida SendTaskSuccess; un Wait no serviria perquè no sabem quan passarà, només el termini màxim, i aquí no convé HeartbeatSeconds perquè el transportista no envia batecs. (4) Un altre Task amb .waitForTaskToken cap a la cua del magatzem, amb TimeoutSeconds: 86400; la decisió de l'operari arriba a l'output del SendTaskSuccess i un Choice posterior encamina segons $.inspeccion.decision (aceptada/parcial/rechazada), amb Default a revisió manual. (5) Task de devolució amb import calculat. (6) Map per línia per reposar estoc.

(d) Retry i Catch del pas 5. Retry generós —6 intents, IntervalSeconds: 10, BackoffRate: 2, MaxDelaySeconds: 300, JitterStrategy: FULL— perquè una devolució fallida és el pitjor que pot passar aquí. Catch sobre States.ALL amb ResultPath: "$.error" cap a un estat RevisionManualDevolucion que publica a alertas-mercadofresco. Mai un Fail directe: deixaria el client sense producte i sense diners.

(e) Compensacions. Aquí n'hi ha moltes menys que al procés de comanda, i el motiu és interessant: el flux va de menys a més compromès, i els passos irreversibles són al final. L'etiqueta de recollida sí que necessita compensació (cancel·lar-la) si la devolució s'avorta abans de la recollida. La inspecció no necessita compensació: és una lectura. La devolució de l'import no es compensa tornant a cobrar —això seria inacceptable—; si es detecta un error posterior s'obre una incidència manual. I la reposició d'estoc es compensa retirant-lo si després es descobreix que el producte no era apte. Lliçó general: ordenar els passos de més reversible a menys reversible redueix el nombre de compensacions necessàries.

Solució 2

(a) Què rep la Lambda. InputPath: "$.pedido" redueix l'entrada a {"pedido_id": "PED-1", "cliente_id": "CLI-9", "importe_eur": 30.0}. Sobre això, Parameters construeix la càrrega, i "id.$": "$.cliente_id" es resol contra el resultat d'InputPath, no contra l'entrada original. La Lambda rep exactament:

(b) Sortida completa. La resposta de la integració és {"ExecutedVersion": "...", "Payload": {"nivel_fidelidad": "oro", "email": "[email protected]", "telefono": "+34600000000"}, "StatusCode": 200}. ResultSelector la retalla a {"nivel": "oro", "email": "[email protected]"} —el telèfon es descarta— i ResultPath: "$.cliente" la insereix a l'entrada original completa, no a la retallada per InputPath. Amb OutputPath: "$" surt tot:

(c) Sense ResultPath. El valor per defecte és $, així que el resultat substitueix tota l'entrada. La sortida seria {"nivel": "oro", "email": "[email protected]"} i AplicarDescuento no trobaria $.pedido.importe_eur, i fallaria amb un error de resolució de ruta. És l'error més comú del llenguatge.

(d) Amb OutputPath: "$.cliente". La sortida seria només {"nivel": "oro", "email": "[email protected]"}. Es perd la comanda igualment, però per un motiu diferent: no és que el resultat l'hagi substituïda, és que s'ha retallat al final. Il·lustra bé que ResultPath i OutputPath actuen en moments diferents i poden espatllar el mateix per vies diferents.

(e) Per què InputPath no afecta ResultPath. InputPath només determina què es passa a Parameters per construir la crida; l'estat conserva internament l'entrada original i és sobre aquesta que ResultPath insereix. Aquesta separació és deliberada i molt útil: permet enviar al servei una vista reduïda sense perdre el context acumulat del procés.

Solució 3

(a) Coreografia. Quatre interessats independents en el mateix fet, sense dependències entre ells i sense res a compensar: és fan-out pur. SNS o EventBridge, segons si cal encaminar per contingut.

(b) Orquestració. Procés llarg (10 dies), amb passos dependents, dues intervencions humanes —waitForTaskToken per partida doble— i necessitat de saber en quin punt va cada alta. Amb esdeveniments caldria inventar una taula d'estat i un vigilant, que és reimplementar Step Functions pitjor.

(c) Cap dels dos com a orquestració clàssica: un Map distribuït, o simplement S3 → SQS → Lambda si no cal control del conjunt. Són 8.000 tasques independents i idempotents; el que es necessita és paral·lelisme i tolerància a fallades parcials, no un flux amb estat. Si a més vols saber quan van acabar totes i amb quina taxa d'error, el Map distribuït amb ToleratedFailurePercentage i ResultWriter és l'opció correcta.

(d) Orquestració. Hi ha una espera de durada desconeguda (la confirmació del proveïdor) i passos encadenats. Màquina estàndard arrencada per la regla de StockBajo, amb waitForTaskToken per a la confirmació i Wait/Choice per reclamar si el proveïdor no contesta en 24 hores.

(e) Coreografia. Un fet solt que interessa a un consumidor, sense dependències ni compensació. Esdeveniment a bus-mercadofresco → cua → càrrega a Redshift. Ficar-hi Step Functions només afegiria cost per transició i una peça més per mantenir.

El procés de comanda de MercadoFresco té ara un amo explícit. mercadofresco-procesar-pedido sap cobrar, reservar l'estoc línia a línia amb un Map, esperar fins a una hora que una persona del magatzem confirmi la caixa mitjançant un testimoni de retorn amb batec, assignar repartiment, publicar PedidoProcesado a bus-mercadofresco i —el que cap coreografia sabia fer— desfer el que s'ha fet quan alguna cosa falla: alliberar l'estoc, tornar el cobrament i, si fins i tot la compensació falla, avisar la Marta per alertas-mercadofresco en lloc de morir en silenci. L'historial de 90 dies va convertir un misteri («per què s'ha compensat aquesta comanda?») en quatre entrades llegides de baix a dalt: el terminal del magatzem perdia el wifi a la cambra de fred.

Les idees que cal endur-se: l'elecció entre coreografia i orquestració no és de gust, la dicten les dependències entre passos i la necessitat de compensar; estàndard enfront d'exprés es decideix per durada, semàntica d'execució i necessitat d'auditoria, i els 51 USD de diferència mensual compren exactament això; el flux de dades —InputPath, Parameters, ResultSelector, ResultPath, OutputPath— és on es perden més hores, i la regla d'or és ResultPath explícit en tot Task intermedi; Retry amb fluctuació (jitter) i errors classificats evita que la recuperació d'una dependència la torni a tombar; i tota saga necessita el seu camí a revisió manual, perquè les compensacions també fallen.

Amb això, MercadoFresco té les quatre peces d'integració: cues per desacoblar, temes per repartir, un bus per encaminar per contingut i fluxos per orquestrar. Però queden preguntes que travessen les quatre i que fins ara hem anat ajornant. Què significa exactament «almenys una vegada» quan el que es duplica és un cobrament? Com s'escriu un consumidor que pugui rebre el mateix missatge tres vegades sense cobrar tres vegades? Quantes vegades cal reintentar, i quan cal deixar de fer-ho per no tombar qui s'està recuperant? Què es fa exactament amb els missatges d'una DLQ un dilluns al matí? I com es garanteix que una comanda escrita a Aurora es publica sempre, si no hi ha transacció que abasti la base de dades i el bus?

A 07-05, «Patrons d'integració», tanquem el mòdul amb les respostes: garanties de lliurament i idempotència amb taula de deduplicació a DynamoDB, retrocés exponencial amb fluctuació, interruptor de circuit per al proveïdor de pagaments, el runbook de la DLQ, ordre i agrupació, el patró outbox per a la doble escriptura, contrapressió, i una taula decisòria final que respon d'una vegada la pregunta «SQS, SNS, EventBridge, Step Functions o una crida síncrona?».