8

I've been looking into this project because the idea of having the whole system be a collection of Lambda functions seems very appealing. As a matter of fact, a few years ago I wrote some software that does pretty much the same as MoonMail does and it is due for an update as some specs have changed. I'm evaluating porting my software to Lambda or just adapting the thing to use MoonMail.

I have the following questions:

In my tests using Serverless, I noticed that when I changed a resource name (like the name of a DynamoDb table) and redeployed, there was no warning and the old table and its contents were destroyed. I think that a simple mistake like an extra character in the config file resulting in the deletion of all data on a database is pretty risky. How do you handle this kind of issue?

Regarding sending email through SES. How do you handle throttling when you reach the sending limit for a particular account? Do you do exponential backoffs? I can't seem to find this in the code base. I'll be very grateful if you could point me in the general area in the repo where this happens.

Julian
  • 8,808
  • 8
  • 51
  • 90

3 Answers3

5
  1. MoonMail has its table names stored in s-templates.json. This file is rarely touched and hence the team hasn't experienced this problem yet, but it is true that danger is still there, and I would approach AWS team with question how to avoid dropping table by simply renaming it in CF.
  2. It does retries in sending limit case with Cloud Watch invocation (MM team correct me if I am wrong, but 99% sure I am not).
Alua K
  • 398
  • 1
  • 3
  • 18
  • 1
    @julian in regards of the throttling question, when it exceeds the sending rate we just keep the email on the queue, and it'll be automatically retried until the queue is empty (see more [here](https://github.com/microapps/MoonMail/blob/master/events/lib/send_email_service.js#L134)). If we hit the daily limit, we just stop the sending process, since the quota is not restored until the next day, but we do some checks before sending a campaign to avoid reaching it. – davids Jan 27 '17 at 09:07
5

You can set DeletionPolicy: Retain when creating your DynamoDB tables to prevent them from being accidentally deleted by Cloud Formation.

If your Lambda is invoked by SNS then you could simply fail when the SES limit is exceeded. SNS would then reattempt delivery using back-offs.

Rich Buggy
  • 289
  • 1
  • 5
3

My approach at the moment is to create the dynamodb in a separate process. So my serverless setup is read-only, no db creation. Because I don't think I would be re-creating my db that often :)

user1736525
  • 1,119
  • 1
  • 10
  • 15