Thank you providing all the details / context. I agree that 3 sorting fields could be a limitation, but this is a restriction that's not easy to parameterize at the moment. > e.g the business team want a rule with a sort_by on price, then brandOrder, the stockQuantity, productViews Let me provide one rationale for this restriction (apart from performance) and then a work around which will help: What we have noticed in practice is that often beyond 3 fields, the tie-breaking has minimal effect o ranking order. In the above example, once you sort on price, brand and stockQuantity, it will be very rare for a product to tie on stockQuantity to require productViews to break that tie for ranking. Also, here's is one way to combine 2 fields into a single int64 field -- code in python below, but easy to adapt to any language of your choice.

def combine_to_64bit(val1, val2):
    """
    Combine two 32-bit integers into a single 64-bit integer using bit shifting.
    
    Args:
        val1 (int): First value that will occupy the high 32 bits
        val2 (int): Second value that will occupy the low 32 bits
        
    Returns:
        int: 64-bit integer combining both values
    """
    # Shift first value left by 32 bits
    high_bits = val1 << 32
    
    # Combine with second value using bitwise OR
    result = high_bits | val2
    
    return result

Using this approach you can actually "pack"

stockQuantity

and

productViews

into a single field and it will also preserve the sorting order like you would get with 4 sorting fields. This computed field can be indexed as part of the document and used in sort_by clause.