Common DynamoDB through a common lambda or each microservice

We have a "shared" layer that has a few resources accessed by different services in the project. There is a table storing shared information (user permission on each of the resources in the project, since it can get big so not being stored in JWT token)

Should we have a Lamba read the dynamoDB table and give other microservices access to the shared lambda only or should we give the microservices access to the table directly so that they can just use a lib method to read the permissions from the table? I am leaning towards direct DynamoDB table access since that avoids the extra hoop through a lambda.

Solution 1:

Both approaches have advantages & disadvantages:

Direct Access to DynamoDB - Good Sides

• The authors of the other Lambda functions can build on their own phases. Faster teams can sprint and not wait for the slower team
• If one lambda function is misbehaving / failing, the other lambdas are still decoupled from it and the blast radius gets limited

Direct Access to DynamoDB - Bad sides

• The effort for writing similar stuff is duplicated in different lambda instances.
• Each lambda can write their own logic and introduce differences in implementations. This could be intentionally designed to work that way but it could also be that one developer misunderstood the requirements
• If this DynamoDB gets poisoned by wrong coding by one of the consuming lambdas, the other lambdas can also go down.
• It becomes hard to measure the reserve capacity, Some of the lambdas can easily become greedy when it comes to read units.

Mediating Lambda - Good Sides

• Reduces the effort required to implement similar logic for different consumers
• If the shared lambda that manages the DynamoDB is performing actions like audit trail storing, you will be able to easily measure the required read & write capacity units.
• If it is decoupled from the consumers, then the failure can be reduced and contained within it.

Mediating Lambda - Bad Sides

• This shared lambda can easily become a single point of failure if the consuming lambdas are expecting return values from it.
• More communication is required between the team managing this lambda and the consuming teams. Politics can easily be introduced by this Lambda :D
• If the consuming teams are developing in a much faster rate than the owner of this shared lambda, it could easily be a blocker to other teams if integration is done poorly.