This is something you can already achieve with search_after and the sort order.
If you want to search "after" the current page you can use search_after with the values of the sort values of the last document returned in the response. To search the previous page, you can reverse the sort order (from desc to asc for instance) and set search_after with the sort values of the first document returned in the response. This way you can retrieve the N documents "before" any documents in the current response and since the sort is reversed you'll also need to present the documents in reverse order. I am going to close this issue because this is something that you can achieve with search_after already. You've already opened a discussion on the forum so I'll be glad to answer additional questions there.

It seems when we do the reverse search_before one record is getting duplicated. any thoughts?

It seems when we do the reverse search_before one record is getting duplicated. any thoughts?

FYI, we had the same issue and it was due to missing values being pushed at the end by default, even for "desc" order.
Which means that switching from "asc" to "desc" is not enough to reverse a sort, you also have to switch missing values' order, e.g.:

{
  "sort": { "name" : "asc" }
}

becomes:

{
  "sort": {
    "name" : "desc",
    "missing": "_first"
  }
}

Reversing the sort order (say from desc to asc) is not really doing what a search_before could have done. The expected result for a search_before kind of solution is that the order of the entries remain same as that of search_after. Example:
If my index had document with ids: 1 to 7, and I restrict my search size to 2, then search result would return the below paginated response on sorting by id desc:

1. request1:

 "sort": [ 
    {"id": "desc"}
  ]

response1:
7, 6

2. request2:

 "sort": [ 
    {"id": "desc"}
  ],
  "search_after": [6]

response2: 5, 4

3. request3:

 "sort": [ 
    {"id": "desc"}
  ],
  "search_after": [4]

response3: 3, 2
4. request4:

 "sort": [ 
    {"id": "desc"}
  ],
  "search_after": [2]

response4: 1

Now, say I would like to go from the last response (1) to just the previous response (3,2). If one reverses the sort order, the request would be:

 "sort": [ 
    {"id": "asc"}
  ],
  "search_after": [1]

The response would be: 2,3

As we can see, the original order of the response which was 3,2 has got reversed to 2,3.

Reversing the sort order (say from desc to asc) is not really doing what a search_before could have done. The expected result for a search_before kind of solution is that the order of the entries remain same as that of search_after. Example: If my index had document with ids: 1 to 7, and I restrict my search size to 2, then search result would return the below paginated response on sorting by id desc:

1. request1:

 "sort": [ 
    {"id": "desc"}
  ]

response1: 7, 6

2. request2:

 "sort": [ 
    {"id": "desc"}
  ],
  "search_after": [6]

response2: 5, 4

3. request3:

 "sort": [ 
    {"id": "desc"}
  ],
  "search_after": [4]

response3: 3, 2 4. request4:

 "sort": [ 
    {"id": "desc"}
  ],
  "search_after": [2]

response4: 1

Now, say I would like to go from the last response (1) to just the previous response (3,2). If one reverses the sort order, the request would be:

 "sort": [ 
    {"id": "asc"}
  ],
  "search_after": [1]

The response would be: 2,3

As we can see, the original order of the response which was 3,2 has got reversed to 2,3.

@BinitaBharati You are right. @jimczi any comments?

Also, the nth item from top is not the same as nth item from the bottom. You need to the proper mapping to handle that.

Can anyone with elastic comment on to why this was closed? This seems like a legitimate feature request? And with the limitations expressed above, the proposed solution by elastic does not work as users would expect.