# Server-client search architecture with PIT in ElasticSearch

**URL:** https://discuss.elastic.co/t/server-client-search-architecture-with-pit-in-elasticsearch/346545
**Category:** Elasticsearch
**Created:** [November 6, 2023, 4:41pm UTC](https://discuss.elastic.co/t/server-client-search-architecture-with-pit-in-elasticsearch/346545 "2023-11-06T16:41:58Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![forceson](https://avatars.discourse-cdn.com/v4/letter/f/ea666f/32.png) [@forceson](https://discuss.elastic.co/u/forceson)
#### Post date: [November 6, 2023, 4:41pm UTC](https://discuss.elastic.co/t/server-client-search-architecture-with-pit-in-elasticsearch/346545/1 "2023-11-06T16:41:58Z")

</div>

I want to use search\_after and PIT to provide consistent search results. The [guide](https://www.elastic.co/kr/blog/get-a-consistent-view-of-your-data-over-time-with-the-elasticsearch-point-in-time-reader) documentation suggests that PITs should be generated in the background and utilized after each search, rather than after every search.

My question here is

If I need to utilize the same PIT id every time, is it safe to expose it to the client so that the client receives the same search results every time? I want to keep the server as stateless as possible, and I want to store the PIT id somewhere, and the idea of using it directly on the server is that when the PIT id is updated (I'm thinking of generating a new PIT after an appropriate `keep_alive` time to keep the data fresh), certain clients might see inconsistent search results.

---

<div class="post-metadata">

### Author: ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)
#### Post date: [December 4, 2023, 4:42pm UTC](https://discuss.elastic.co/t/server-client-search-architecture-with-pit-in-elasticsearch/346545/2 "2023-12-04T16:42:07Z")

</div>

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