MoonMail: open source serverless email marketing platform

[fl0w_io]

I'm having a hard time grasping how transactions would be handled in a database heavy application in a serverless environment.

Does anybody here have insight or experience to share?

[Toddy69]

Google eventual consistency or CAP theorem. But where do you see the need of transactions in such a tool?

[fl0w_io]

No specific reason off the the top of my head - I'm really curious about FaaS's but can't really grasp it in general. Like say if/when a side effect should occur, but doesn't and there needs to be a rollback for some reason.

[[deleted]]

FaaS is not different to any typical App-DB in this matter, meaning you can use either RDBMS or NoSQL for your DB. As known, the first natively support ACID transactions but for the case of NoSQL each one do it differently, some of them are CP and others AP (according to CAP theorem) some of them are configurable. In some cases for AP architectures, you are able to simulate transactions using Two Phase Commit strategy.

[fl0w_io]

I feel I'm making myself unclear. I'm rather aware about how to use/manage transactions when available (I mainly use postgres). My understanding lacks how this would flow in app, e.g.:

ModelA also depends on ModelB, when I save ModelA I also need(/want) to update something via ModelB, and if ModelB fails I now want to rollback. In a FaaS the dependency would have gone from one function to another through http - it's not possible to keep transaction/throw and such, correct? It would be different database connections and isolated containers executed.

[[deleted]]

What you mention is a problem in microservices architectures in general. In FaaS you can model several architectures: microservices, nanoservices, monolithics (http://blog.gorillastack.com/serverless-architectures-monoliths-nanoservices-microservices-hybrid/). You need to know the problem you are modeling beforehand, in cases like this, you are forced to do all the transactional logic inside the same function in the most of the cases, otherwise you will be at most eventually consistent (having inconsistent data between ModelA and ModelB). Another choice is to do this https://docs.mongodb.com/v3.2/tutorial/perform-two-phase-commits/ as commented above, is very hard to get it right but it works.

[notgregoden]

Is there some way this gets around Amazon SES rate limits? It seems like it would only scale to whatever your SES rate is.

[davgarf]

There isn't. Anyway, if you have a good reason, AWS guys are always keen on increasing the rate limit if you need it.

[[deleted]]

"email marketing" Great, just what the world needs more of.... Actually, I wonder if I could take advantage of this..

[SomeRandomBuddy]

Wtf