---
# System prepended metadata

title: 'ADR: Segments'

---

# 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