When we started building serverless applications back in 2017, there was quite a lot to learn. So we'd like to share some mistakes, important pieces, and concepts for production-ready serverless projects. This time: delivery strategies

1. delivery strategies
?
Serverless on AWS
lessons learned #6
Are you really
production-ready?

2. In most event based
systems you’ll find 3
delivery strategies:
● exactly-once
● at-most-once
● at-least-once

3. exactly-once
Each message is
delivered exactly once.
This is the hardest to
achieve and probably
the most expensive*
one. *in terms of implementational and
computational effort

4. at-most-once
Each message is
delivered at most one
time, or not at all.
This is the cheapest*
but has its use cases.
*in terms of implementational and
computational effort

5. at-least-once
Each message is
guaranteed to be
delivered at least once.
But can be delivered
twice or even more
often.

6. Although you should
know all three, at-
least-once is what
you’ll face the most in
serverless projects.

7. What does this mean
for my architecture?

8. Since at-least-once is
already set for a lot
of services, you
should consider the
following:

9. Can my system handle
the same event twice,
or do I have to take
measures like:
● ensure idempotency
● deduplication

10. Are there alternative
services to ensure
exactly-once delivery,
if needed?
Like FIFO Queues and
Topics.

11. Can I implement my
own strategy for the
existing services?
e.g.:
exactly-once: using
redis for state
at-most-once: async
service calls

12. delivery strategies
?

13. thumbs up, comment, share
What are your thoughts?
Is anything important missing?
If you liked it, please leave a comment.
connect with me!