In V2, we should split powertools-idempotency into sub-modules, so that we have powertools-idempotency containing the interface to the module, and powertools-idempotency-dynamodb providing a DynamoDB-backed concrete implementation.
Why is this needed?
Allow us to provide pluggable extensions of the module (e.g., introducing an SQL backend) without increasing the user's deployment size
Follow the pattern introduced by the splitting of powertools-parameters in #1402
Force a hands-on review of the module as part of our overall v2 work pipeline
Summary
In V2, we should split
powertools-idempotency
into sub-modules, so that we havepowertools-idempotency
containing the interface to the module, andpowertools-idempotency-dynamodb
providing a DynamoDB-backed concrete implementation.Why is this needed?
Which area does this relate to?
Idempotency
Solution
No response
Acknowledgment