AWS Summit ANZ 2021 - Design patterns for success in serverless microservices

[@fahadhasan1621]

A comprehensive yet compact presentation on design patterns in server-less micro-services architecture utilizing available lambda integration services for further utilization of AWS managed Kubernetes service that is Fargate. All of this makes the most efficient and cost effective utilization of cloud resources and further makes the lives of developers and architects much easier. Two thumbs up! 👍 👍

[@huevosyitz]

Very nice presentation. Easy to understand. just the right amount of detail. Thanks

[@caninelover]

Hello, I learned a lot from this presentation. I have a question regarding SNS: if multiple users are simultaneously using the application, will the SNS messages get lost or sent to the wrong user? Or will the correct user (subscriber) receive the correct response? I'm just curious if SNS automatically directs the response message to the correct caller.

[@awssupport]

Hi, there. This resource includes helpful information about SNS and may address your questions: go.aws/3VKlsfJ. 🔎 For any further questions, please reach out to our free community of helpful engineers at re:Post: go.aws/aws-repost. 🤝 ^ZP

[@MohamedAli-h7q8b]

Awesome presentation thank you

[@amazonwebservices]

Thanks for the compliment, Mohamed! 😍 🤝 ☁️

[@MrMylonz]

In the demo the API transaction Order ID 3 is overwritten with second request using the same order id 3, I assume in a real world implementation this would normally be an invalid transaction, would you record this as an error event or discard it ?

[@awssupport]

I'm sorry to hear that your having difficulties, Myles. I've forwarded your question to our Support team for further review. In the meantime, please feel free to ask our community of experts in re:Post for further guidance: go.aws/aws-repost. ^KR

[@aidataverse]

Very much useful .

[@amazonwebservices]

That's great to hear! 🙌

[@abc_35p]

I don't understand how this helps database contention. You've separated reads from writes at the service level, but the RDS database still gets written to, just in a roundabout way. So if too many writes were causing degradation in service, those writes are still being done, maybe with a 500ms delay, but for example 1000 "place order" calls per second still ends up creating about 1000 writes per second on the RDS database, so you'd still get the same performance degradation. Unless you for example limit the RDS write throughput via something like setting a low reserved concurrency on the lambda which writes to RDS, but that isn't mentioned.

[@linuxadmin]

Search service now pulls from the elasticache, not the Aurora/RDS, so the contention for resources on RDS is alleviated, although reporting is still reading from RDS, I suppose the assumption is that search is more frequent/impactful than reporting, as is usually the case.

[@pk4866]

Awesome presentation skills

[@hazarathramakrishnan6636]

If you are giving demo it should be from scratch