I'm currently working on a project where I use DynamoDB as my nosql database. Before I started I tried to learn how to model nosql databases since its really different to our known relational databases. I learned that I have to stick on the single table model.
Im using DynamoDB Streams to aggregate some data, for instance the customer count for a product (there are some more complex cases than that). Since I have only one single table, my lambda function writes in the same table, from which the stream came. Add new customer to TableA -> DynamoDB Stream triggers Lambda for TableA -> Lambda updates a row in TableA -> DynamoDB Stream triggers Lambda for Table A -> Lambda function terminates. If I understand it right, this scenario could lead to an infinite loop since the first insert trigger triggers an update trigger. This is something im escaping in my lambda function.
My question now is
Am I getting billed for two lambda functions and two DynamoDb streams each time I make an insert in my db?
If yes should I ignore the best practise way of a nosql db and split the table into multiple or should I invest the money ? Because I am doubling my bill in this case.
What are the cons of splitting my table in multiple tables ? Would be the effect of the cons that big ?
1 Answers
In general I would advise against such loops. In distributed system loops of dependencies could result in in various kinds of undesired effects. In an architecture based on DDB + Lambda, some of these effects are eliminated but I would still try to avoid it. On top of that in such an architecture there is also the risk of infinite loop of Lambda invocations. This could result in a significant financial price. Even if you write your best code (and even implement safety checks against such loops) I think the best course of action is design the architecture such that loops are not possible.
Thus, I would definitely split the DDB table into two.
The negative side of splitting into two tables is this: instead of retrieving just a single item your application may now need to retrieve two items (from the two tables) to get the same amount of information.
