---
# System prepended metadata

title: 'ADR: When to validate customers count?'

---

# ADR: When to validate customers count?


## Background
* Each customer could be a part of `n` number of segments. `n` is configurable. Let's call `n` as _slots_ henseforth and assume its value is 20.
* Each promotion (possibly) creates a new segment, so there is a 1-1 mapping between promotion and segment. 
* One merchant can create multiple promotions.

Given the points above, we can see that a merchant can possibly consume all available slots (n) of a customer.

There are a few optimisations we can do to reduce this occupation of slots by a single (or handful) of merchants.
1. Create the segment on promotion's start_date, instead of when the promotion is created
2. Delete the segment when the promotion ends
3. Delete the segment if the merchant deletes, or deactivates the promotion

For us, #2, and #3 are straightforward to do. However, #1 poses some complications. Let's talk about the process flow when creating the promotion.

### Flow
1. MPS calls MSS's /sync-segment with 
    * merchant_id
    * segment_type
    * start_date
    * end_date
3. MSS fetches the customer_id for merchant_id, and segment_type from its local DB
4. MSS filters out the customer_ids for which slots are filled up `(number of segments > n)`
    * If the list from #3 is > 0 
        * MSS accepts request
        * Increment counters for customers (filtered list)
    * else
        * Reject the request

The step 4 from flow above can happen at two different times.
1. On promo creation
2. On promo start date

### On promo creation
Flow remains the same as described above. Validation happens synchronously, and merchantnt gets the response at promo creation time.

Pros:
1. Merchant gets a sync feedback
2. If there are no customers at creation time, we don't create the promotion

Cons:
1. A single merchant can take up more slots than necessary, since we are incrementing `n` right when someone creates a promotion.
2. At creation time, we don't have the true representation of a segment for the duration of promo. Eg: The set of new_users today is different from what it would be a month in future.


### On promo start date
Here, we don't validate the segment list at promo creation time. Instead, we just accept the request.

On start date:
1. Fetch the customer_ids
2. Filter customers who've number_of_segments < `n`
    * If customers > 0
        * Create a segment, sync these with SS
        * Increment counters (n) for these
    * Else
        * Ignore

> A simple check could be done at this time eg: check if there is at least one customer in segment, without doing slots filter

Pros:
1. Only relevent segments are created at any point in time
2. More slots available
3. Represents the correct state, since the segment is read on promo start date

Cons:
1. Merchant won't get a sync feeback. There is a possibility that we create the promotion but don't have any audience for it on start date
    * One way to communicate this with merchant would be to expose the audience count on promo-details page. 