Currently, both the monolith and swatch-contracts have a dependency on the subscription table.  The monolith's use comes from the TallyResource.getCapacityReport method.  These capacities are ultimately used by getTallyReportData when generating a report using running totals.  The API call that leads to this is GET /v1/tally/products/{product_id}/{metric_id}

The monolith also still has the GET /v1/capacity/products/{product_id}/{metric_id} endpoint exposed although it is unavailable due to the proxy settings

The monolith is directly reading capacity information from the subscription table, but swatch-contracts also reads from the subscription table.  We have two different components that have a claim to the same table.

This card encompasses the work to

• Remove the GET /v1/capacity/products/{product_id}/{metric_id} endpoint from the monolith
• Refactor the monolith so that it is no longer performing direct reads against the subscription table or any tables in the subscription hierarchy:
  • offering
  • sku_child_sku
  • sku_oid
  • sku_product_tag
  • subscription
  • subscription_measurements
  • subscription_capacity_view
• The monolith should instead fetch capacity information that it needs from swatch-contracts.

This card is a follow-on from SWATCH-3895.  In 3895, I made changes to the liquibase scripts to move nominal control of the subscription hierarchy to swatch-contracts.  However, if both components maintain a direct link to the hierarchy (by mapping the entities), it will make migrations extremely difficult in the future.  The migration will need to be made in both components with special Liquibase preconditions to handle the case where the migration has already been applied.