SNS - possible to send multiple messages in one call?

Serverless Framework
1

I have a lambda that recieves dynamodb events.

For each event I want to to trigger another lambda to do some processing on that event.

I had thought that calling this other lambda asynchronously via an InvocationType.Event was maybe too many separate operations - as a separate call is needed for each lambda invocation , so I thought maybe sending multiple messages at once to an SNS queue (which would trigger the lambda) would be a better idea. However it seems that one can only send one message at a time to an SNS topic ? is it not possible to post multiple in onbe call ?

2

The SNS API’s publish API only allows one topic/message per call.

3

In situations where I have a Lambda processing events from DynamoDB that need to trigger multiple other Lambda I find the best solution is to publish a generic message to SNS then use the fan out functionality by configuring multiple Lambda as subscribers (just add the same topic as a trigger to each Lambda).

For example: When a new user is added to DynamoDB you could publish a “created” message to the “user” topic then subscribe two Lambda to the user topic (one to send a welcome message and one to add the user to a mailing list)

4

I assume though if only one Lambda needs to be called then a direct call to Lambda is preferable over SNS scenario

5

Not really. SNS provides loose coupling that a direct call doesn’t.

If you only need to call one Lambda then I’d question why you don’t just put that functionality into the Lambda processing the stream.

6

well, the thing is the Lambda that processes the stream can receive a bunch of events at once… so doing a bunch of work there (3 rest calls which I want to do together in parallel) would be too much for that Lambda itself

7

You would subscribe multiple items to the topic. Topic called once, many subscripted items get the message.

1 Like
8

so you are in favor of SNS over a lambda call ?

9

I mean either can work, but it appears that because of the timeout issue and/or multiple requests doing a direct call won’t work. So, options are to trigger other multiple lambdas via sns by having them subscribe to the sns, or something else like sqs queues or even dynamo again by storing data in a a table to process. From the little info I know about your use case, having a lambda call an sns to invoke multiple other lambdas asynchronously sounds like a good approach. If you did sqs or a dynamo table, you’d just have another task running on a schedule to process results from the first task running on a schedule. So, you’re not gaining anything. That is, when you read the stream data from dynamo and realize you need to act on it, that should be the point where you do the action (i.e. call the sns to fan out to othwr lambdas).

10

theres actually no need for fan out right now in my use case - there is just one job to be done for each dynamodb event - so there would only be one subscriber lambda. Sure its more future proof to have sns, but just wondered which was more economical (in terms of api call) - calling a lambda directly and asynchronously or publishing to SNS

11

My general rule of thumb is that if you have one Lambda directly invoking another then you’re doing it wrong. There are obviously some use cases for this but generally don’t do it. Use SNS because it decouples the processes and adds retries. You get a similar result with Kinesis streams and DynamoDB streams. Don’t use SQS because it’s not currently supported as an event source for Lambda.

When setting up topics I try to use names like “user created” instead of commands like “send welcome email”.

12

good point,

btw do you ever have to add any de-dupe logic for SNS messages when there is only one subscriber ?

13

Your Lambda’s should be idempotent anyway. If they are then de-duplication of messages from SNS doesn’t matter.