MENU
An ecommerce site has dynamic shipping cost calculation. it allows the customers to see their potential shipping costs on the Product Detail Page before adding an item to the cart.
For this feature, shipping touts are calculated using the following logic:
* Set the shipping method on the Basket
* Add the item to the basket, calculate the basket total and get the shipping cost for this method
* Remove the item from the Basket to restore the original state
* The above process is repeated for each shipping method
During the testing it was discovered that the above code violates the spi.basket.addResolveInSameResquest quota.
What should the Architect do to resolve this issue and maintain the business requirement?
To resolve the issue of violating the spi.basket.addResolveInSameRequest quota and to maintain the functionality of dynamically calculating shipping costs for items before they are added to the basket, the best approach is:
Option D: Wrapping the adding of product and shipping cost calculation in a transaction, which is then rolled back to restore the original state. This method ensures that the system can calculate potential shipping costs without permanently altering the state of the basket. This approach keeps the basket's original state intact while allowing for multiple shipping calculations, effectively managing the load on system resources and adhering to platform quotas.