<p>The information provided is not really sufficient for a really valuable answer, but you may consider the following:</p>
<ol>
<li>It seems to me, that you have more than one RID for one VID but only one VID for each RID. If this is true, it seems more reasonable to me to store this 1:M relationship in the Registration DB.</li>
<li>In what circumstances do you need the Validation schema information behind the VID?
What I mean:</li>
</ol>
<ul>
<li>Do you have a method, which returns all the registrations connected to specific VID?</li>
<li>Or may be, you have a method, returning the Validation schema used for specific registration?</li>
</ul>
<p>Do you see the difference and why this questions is important?</p>
<p>Finally, you may be interested in <a href="https://arxiv.org/pdf/1906.01553.pdf" rel="nofollow noreferrer">this article</a>, especially in chapter 4.4 Decentralisation -&gt; Shared persistence.</p>
<p>You don't share the same storage, but it seems to me that it is possible, that you have split it more than needed and it may be a good idea to combine the Registration and the validation services into one. Of course, this is very speculative statement. But if you are unsure if I am right or not, ask yourself:</p>
<ul>
<li>Does other services / clients use the Validation service?</li>
<li>Does the Validation service represent a dedicated business unit / domain or is it just part of other's unit processes?</li>
</ul>
<p>And things like that.</p>
<p>And finally: The microservices world doesn't recommend where to put your data, but what to think about, when you decide where to put your data and the main things you may consider, are:</p>
<ul>
<li>Your services should be deployed autonomously and should operate autonomously.</li>
<li>Your services shouldn't share their storage (because of the previous one)</li>
<li>You should be able to scale individual services by need, without touching the other (this is why we need autonomous deployment and operability)</li>
<li>The granularity principle is very dependent to your concrete project. When you decide &quot;how much&quot;, you should take care of the business domain and the ability to maintain all other principles.</li>
</ul>
<p>Remark: The principles above are by no means exhaustive, but I hope, that all this gives you some directions to get your job done.</p>
How to design validation rules between microservices?
<p>We have two Microservices (M1 and M2) and each microservice has it's own schema DB1 and DB2.</p>
<ol>
<li>M1 receives the request for registration</li>
<li>M1 calls M2 for validation</li>
<li>M2 returns validation results (with validation id - VID) to M1</li>
<li>M1 completes the registration and persists in DB1 and each registration will have Record Identifier (RID)</li>
</ol>
<p>My question here is where do we persist the relationship between RID and Validation Results for RID?</p>
<p>Should they be persisted in DB1 (associated to M1) or DB2 (validation schema)?</p>
<p>If the relationship needs to be persisted in M2, then M1 has to make a call to M2 with RID and VID (validation id)</p>
<p>what is the recommended approach in microservices world?</p>