The final part of the Taco Bell segment resonates. Serverless does make it easier to involve more people in a meaningful and productive fashion on a project.
I would say the choreography approach (in this case) had poor cohesion rather than being too loosely coupled. It seems like the order process would need to have some sort of cohesive/centralized state to protect any invariants. For instance, can an order ever be delivered before it's placed? Can an order be both cancelled and delivered? Can an order be delivered three times? Out of curiosity, do you store the state of the order outside of Step Functions?
![AWS re:Invent 2019: [REPEAT 3] Serverless architectural patterns and best practices (ARC307-R3)](http://i.ytimg.com/vi/9IYpGTS7Jy0/mqdefault.jpg)
The final part of the Taco Bell segment resonates. Serverless does make it easier to involve more people in a meaningful and productive fashion on a project.
Really cool to seeing Middy being mentioned here! 🎉
I would say the choreography approach (in this case) had poor cohesion rather than being too loosely coupled. It seems like the order process would need to have some sort of cohesive/centralized state to protect any invariants. For instance, can an order ever be delivered before it's placed? Can an order be both cancelled and delivered? Can an order be delivered three times?
Out of curiosity, do you store the state of the order outside of Step Functions?
Great talk, Robbie!
very clear. Good comparison.
Great talk, thanks!!!!
26:06 - If every message needs to call Database to check if it's duplicated, isn't it a limit of efficiency?
reading data from a database (a simple select id where id = x) is really not an expensive statement in terms of resource/time consumption
Thank you so much