Update docs/developer-docs/smart-contracts/best-practices/idempotency…

….mdx

Co-authored-by: Roel Storms <[email protected]>

docs/developer-docs/smart-contracts/best-practices/idempotency.mdx

@@ -56,7 +56,7 @@ Moreover, the ICP/ICRC ledgers use the `created_at_time` parameter to limit the
 
 But even with this improvement used in the ledgers, the time window approach implicitly assumes that the client will be able to get a definite answer to their call within the time window. For example, after the 24 hours expire, the user cannot easily tell if their ledger transfer happened; their only option is to analyze the ledger blocks, which is somewhat tedious, and has to be done carefully to avoid asynchrony issues; see the section on [queryable call results](#queryable-call-results).
 
-Furthermore, just using a time window for deduplication does not guarantee that the memory will stay bounded. In principle, arbitrarily many updates could happen within the time window, although this is bounded in practice by the scaling limits of the ICP. The ICP/ICRC ledgers thus also define a maximum capacity: the number of deduplicated transactions (i.e., deduplication IDs) that they will store in their deduplication store. Further transactions are simply rejected after the capacity is reached, until the window passes and old transactions can be removed from the deduplication store. Yet another extension of the approach is to make the time window simply the guaranteed lower bound, and just store deduplication IDs until the capacity is reached. This way, the clients obtain a hard deduplication guarantee for the time window, and a best-effort attempt to deduplicate transactions even past the window.
+Relying solely on a time window for deduplication does not guarantee bounded memory usage. In theory, an unlimited number of updates could occur within the time window, though in practice, this is constrained by the scaling limits of the ICP. The ICP/ICRC ledgers thus also define a maximum capacity: a limit on the number of deduplicated transactions (i.e., deduplication IDs) that can be stored in their deduplication store. Once this capacity is reached, further transactions are rejected until older transactions expire from the deduplication store at the end of the time window. Yet another extension of the approach is to make the time window simply the guaranteed lower bound, and just store deduplication IDs until the capacity is reached. This way, the clients obtain a hard deduplication guarantee for the time window, and a best-effort attempt to deduplicate transactions even past the window.
 
 An alternative is to do away with the time window, and store the deduplication data forever. This requires multiple canisters to prevent exhausting the canister memory, similar to how the ICP/ICRC ledgers store the transaction data in the archive canister. This shifts the tedious part of querying the deduplication data (e.g., ledger blocks) from the user to the canister.