3

We are building a new product in real estate space and the end users of this product are not so tech savvy. To have better user experience with our product, we want our users to find relevant things quickly and easily. Apart from a simple UI, a universal search bar seems to add value.

The search bar with auto-complete will allow users to find information such as - their billing history (past payments, invoices..), help content, support content from helpdesk tickets, data from chat history and such.

We are going with microservices architecture for our services such as user management, help ticket system, chat, CMS for help content and more. The question is how do we build this central search service that can index and store all user content from all these services that user will be able to search.

Would each service would dump data into elasticsearch to be indexed and made available for search which then a search service than query? Say when a support ticket is open, or a chat conversation is closed would the relevant microservice copy this data into a service like elastic search? Would it be better for the microservices to push such data to a queue which then is consumed into elasticsearch?

I'm open to any ideas and thoughts on how search is architected nad the best practices there of. Happy to provide more information on our service if it helps with a better answer.

UPDATED:

  • There is one DB per microservice
  • Search need not be real time
  • Not too worried about the load and we will go with hosted search - AWS cloudsearch or elasticsearch
mrcasa bengaluru
  • 51
  • 3
  • 2
    It really depends, your question is too broad. Do you have db per microservices or one central? Do you have active record or event sourcing? Do you need real time search or it is not necessary? What about availability of you search, do you expect high load? – Tomasz Maciejewski Feb 05 '18 at 11:55

3 Answers3

3

I would somewhat disagree with @Ewan. While yes, you can wind up with a big blob of unstructured data, that’s only an inevitable consequence if you don’t work to prevent it.

In counterpoint, I’d argue that the public internet is actualy a collection of microservices, most of which happen to serve HTML documents of one flavor or another. Google, Bing, etc are essentially central search services for that “enterprise”.

So, the way I would proceed for your use case would be to build that central search cluster (or use the AWS one) but pay strong attention to what you index, how, and then how you reference the source service. You want to index in advance and then serve upon request, in my experience, that provides the best overall user experience. The thing that you have to decide is how much information and in what schema do you want to store the indexes items. This will require some tuning and will depend on what parts of the source data you want searchable. The answer might be “everything “ but it probably isn’t, and if it isn’t then there are efficiencies to be gained by limiting the index scope.

Paul
  • 3,277
  • 1
  • 17
  • 16
2

I Would avoid a 'Central Service' you can end up with a big blob of unstructured data.

Presumably once the user has found something in there, you will want to do something with the result and this will require structured data.

Each MicroService should be responsible for its own data and supply a search function.

When the user does a global search, you can either hit all the MicroServices, or do some processing to try and narrow down the type first.

Ewan
  • 70,664
  • 5
  • 76
  • 161
1

We are building a new product in real estate space and the end users of this product are not so tech savvy. To have better user experience with our product, we want our users to find relevant things quickly and easily. Apart from a simple UI, a universal search bar seems to add value.

The search bar with auto-complete will allow users to find information such as - their billing history (past payments, invoices..), help content, support content from helpdesk tickets, data from chat history and such.

I think you've failed to do the first step of software design (researching use cases) so you're throwing in all kinds of nonsense into your project (a universal search, chat, a kitchen sink, maybe an ice-cream machine on Thursdays) using "shotgun logic" (more projectiles means more chance of hitting a target, even when you don't know where the target is).

If you want users to find relevant things quickly and easily, then you need to know what is relevant for the specific user at the time. For example, someone looking for a house to rent (in a certain area, in a certain price range) is not going to want a universal search that pollutes the search results with garbage intended for people selling a house. They don't want a universal search, they want a "use case specific search".

For another example, someone looking for their billing history will want to log in and click a "billing history" link to see a chronological list, and won't want a universe search (and probably won't want any kind of search).

Community
  • 1
Brendan
  • 3,895
  • 21
  • 21