Currently, when quantity changes on a subscription, we terminate the current subscription record and create a new record with the same ID but with the updated quantity, a start date of the current time, and an end date of the original subscription record.

After the data consolidation between the contracts and subscription tables, we will keep doing the same. However, if we're going to get rid of the contracts table, and use only the subscriptions table, we might return duplicate subscriptions if the quantity changed during its lifetime.

The objective of this spike is:

• to verify if there is a potential risk in the Contracts API to return multiple subscriptions and identify the logic that would need to be updated
• to analyse if it's worthy to work first in SWATCH-2660 which is meant to stop duplicating subscriptions after quantity changes
• to find / purpose component tests to verify this logic
• verify subscription measurements matches with contract metrics