title: How To Use ElasticSearch as a search Engine for relational structure in a micro-services envirement
body: <p>I’m working on an application that is using a relational database <code>Mysql</code> for most of the entities and it is constructed in a microservices architecture and each service is using a separate MYSQL database.</p>
  
  <p><a href="https://i.stack.imgur.com/KiqEL.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/KiqEL.jpg" alt="enter image description here"></a></p>
  
  <p>Now I’m trying to implement a search engine for publications using elasticsearch as a middleware funnel to be able to search by all entities that are related to the publication object even from different services with different databases.</p>
  
  <p><strong>What will be the best way to index the publication object?</strong></p>
  
  <ul>
  <li>I have 3 options in mind:
  
  <ul>
  <li>Create a full publication type with multi-nested object types?
  
  <ul>
  <li>problems:</li>
  <li>Duplication of all the entities from different services</li>
  <li>Hard to update for example in case of updating an instruction</li>
  </ul></li>
  <li>Create a different publication type with all fields from other objects then normalize the data when inserting or finding the data.
  
  <ul>
  <li>problems:</li>
  <li>normalizing data on inserting and on finding is costly</li>
  <li>hard to maintain and to update</li>
  </ul></li>
  <li>Insert multiple separated types similar to the relational database then do multiple queries to find the final object, for example, if we want to find a publication by user_name we have to find the user first then use the user_id to find the publications.
  
  <ul>
  <li>problems:</li>
  <li>we have to make more than 1 query to get valid results</li>
  </ul></li>
  <li>Use has_parent, has_child relation but in this case the child is publication and it is having multiple many-to-one relations so multiple parents.</li>
  </ul></li>
  </ul>
  
  <p>I could be going in the wrong direction please share your feedback if you think I should use a different technology</p>