E-commerce products with prices per customer

Hello there!

Let me give you the use case.

I need to build this b2b commerce where the prices for each product is different for every logged in customer. One of the functionalities is, the customer should be able to filter and sort the list of products by price.

From what I've read so far, storing the prices into the product index could be quite a performance penalty.

Generally speaking in the context of a e-commerce site and especially with price scenarios like the one I mentioned before or discounts per customer etc where the data shouldn't be in the same index is quite difficult and honestly I couldn't find much around the internet.

How would you go about this on how I should tackle this kind of scenarios? I would appreciate a hint on this.


Welcome to our community! :smiley:

Is it safe to say that there's a base price for each item, and then you change that based on the customer's discount level?

Wow, thank you for the greetings!

That could be a use case, sure. In my particular use case the price for each customer comes from an ERP so there is no base price for the products hence base price is 0.

If it helps the prices come in the following format:
customer_id - product_id - price - percentage_discount

How many products and customers do you have?

The products are about 50.000 and the customers I think would be between 100 and 200.

Then I would probably flatten the data and store product information with price for each customer. It will be easy to update and query and should not take up much space even if data this way is duplicated.


So you mean by using nested objects something like this:

  "name": "Product 1",
  "Description": "Product description",
  "prices": {
      "customer_id": 1,
      "price": 1000,
      "percentage_discount": 19 
      "customer_id": 2,
      "price": 1300,
      "percentage_discount": 10 

That would make sense given that I need to sort using the price.

What if I had 1000 customers? That would be a lot of data and would be more difficult to update all these prices for a given customer.

I know of course the answer would come by testing a variety of solutions and then compare the search performance but since I am new to ES I'm trying to find what would be the thinking process with those kind of relationships.

I found a very good article explaining the pros and cons regarding the right data modeling when we are dealing with relationships but it would be nice to chat about it. Unfortunately there aren't many real world example out there from what I have seen.

No, I mean a document per product and customer without nested documents. This means that you will have 200 documents for each product if you have 200 customers but it aligns well with the feed you get from the ERP system.

1 Like

Hm, yes that looks interesting. Performance wise it would be pretty fast since each document would be completely flat and using the customer id as a filter would also cache the results. Sorting by price would be pretty easy since the price attribute would be level 0 in the document.

Thanks for your suggestions. I'll mark this as a solution to this thread.

Please for anyone else feel free to share your opinions on this!

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.