Currently I have a spring boot microservice that stores list of items in MongoDB.
Now I want to add autosuggest functionality when searching by item's name (partial/fuzzy search).
I'm thinking of using ElasticSearch's built in REST API for this.
My plan is to send POST and PUT to ElasticSearch's REST endpoint everytime I do insert / update data in MongoDB.
Now the webclient can just use ElasticSearch's REST API to get autosuggest data given the keywords the user type on search bar.
Is this the intended way to use ElasticSearch? How do we scale this? Or is it better to create a separate microservice using spring java and elasticsearch client to achieve same thing?
You can achieve the functionality using both ways and its actually an opinion based question but I would still try to list pros and cons based on my experience.
I am assuming here that mongoDB is your source of truth for data, while ES is used only for search.
This would save you the extra overhead which microservice brings: like deploying another app, infra, releasing the jar which contains the same POJO or entities, used by your mongo and ES application. Major overhead is the extra network hop, as if in this case, once update is successful in your mongo app, then you would send the request to ES app, which in turns update the elasticsearch application, you can send request parallelly to Elasticsearch app but this would lead to inconsistency, As an update might fail in MongoDB, hence both ES and MongoDB will not be in sync.
As long as you managed the consistency between your source of truth and elasticsearch, would bring you the typical benefits of microservice, like separation of concern, faster release cycle, less complex code, choice of language and frameworks etc, improved developers productivity, etc.
Again, your question is not specific to elasticsearch and it's more of a microservice vs monolith which totally depends on your use case and you can find a lot of debate on these online, but one you should definitely watch and is one of my favorites is uber architect's regret on scaling it to 1000 microservices.