# ADR: Segments

## Workflow

1. MPS calls MSS API to sync segment with merchant_id, segment_type, start_date, end_date. MSS returns segment_name. (MSS gets to decide on implementation. managing one segment for merchant_id/segment_type vs. one per promotion)
3. MPS creates promo in markdown with segment_name
4. MPS saves locally

## One segment per merchant usercase versus per promotion

### One segment per merchant usecase

To support one segment per merchant usecase:
- Check if segment exists
- If yes: check segment.end_date < promotion.end_date
- If yes:
- Extend segment.end_date
- If no:
- Do nothing
- If no:
- Create a new segment with end_date = promo.end_date

Pros:
- No duplicates for overlapping promotions.
- Real-time updates may be easier to support since only one segment copy (per definition) has to be kept up-to-date
- Keeps no. of segments low even if segments are created during promo creation (and not promo start date). eg: If merchant creates 10 promos together, during promo creation, mss will create only one segment on segmentation service. As compared to async flow which will end up creating 10 segments.

Cons:
- SS would have to support a new API to extend end_date
- More complexity on MSS. It has to check if segment exists. Has to call new API to update end date.

### One per promotion

- Create new segment for every promo request.

Pros:
- Less complicated
- Fewer changes on SS

Cons:
- If we need real-time updates, all promo segments would have to be updated.
- Needs a scheduler to sync segments only on promo start date. eg: If a merchant creates multiple non-overlapping promotions, we might end up creating multiple segments (unless we sync segment on promo start date)
- Will create duplicates for overlapping promos