Take this as an example here. You've got to weigh two approaches on how best to handle the spread of pilot data between two microservices - Microservice A handling information about employees and pilots, and Microservice B handling bookings - both of which have trade-offs in terms of complexity over performance, with consequences for data consistency and adherence to the principles of microservice architecture. Let's break these apart and look at what would be the best one for the situation:
Advantages: Decoupling of Microservices: Here, the Microservice B will not rely on Microservice A totally because it will have a duplicate copy of the pilot information necessary. Read Efficiencies: Microservice B can read pilot data directly so will be pretty efficient for reads against bookings without crossservice calls. Disadvantages Data Duplications and Synch: Bringing data duplication between services introduces the need to maintain consistency and carry on updating your data in Microservice B as soon as updates are made to Microservice A through events or otherwise. It adds a bit of complexity concerning eventual consistency handling. More Coupling: You'd have synchronization, error handling as well as potentially race conditions depending on whether the data in A and B get out of sync. Violates one principle of Microservices: Critical business data such as pilot data can't be duplicated in multiple microservices since it violates the Single Source of Truth principle; hence, deep synchronization mechanisms are also required. 2. R&D Both Pilot and Person Tables of Microservice B Duplicate Data Ends This will replicate Pilot and Person in Microservice B, that will contain the full details of the pilot along with his person; these can be used in a booking operation.
Benefits Autonomy: Microservice B will have all information needed to be there for its bookings to be serviced without having to make calls outside of itself for that functioning. Fast Reads: All operational support data for reservation booking will now come from a single database. It will result in reduced query latencies related to booking data. Weaknesses This means heavy data duplication: you are duplicating Person and Pilot and, therefore, redundantly represent data which will inevitably be exposed to inconsistency. High Complexity When data is duplicated in two places, it becomes impossible to maintain. It is so complex that the company has to check for updates of the pilot data at Microservice A in Microservice B. As the scalability of the system grows, it is complex as well as buggy. In fact, this is against the Single Source of Truth principle. Because you are holding data in the form of duplications, things should be held differently in microservices architecture. 3. In the Microservice B, retain to PilotId-Without Dups The bookings table in Microservice A has only one pilot id while at the email job by Microservice B, all pilot details like name and email address are fetched from Microservice A whenever in demand. Benefits: Duplicated pilot data: in the Microservice B, you don't duplicate pilot data; the actuality remains within the Microservice A. This really goes well with the principle of the Single Source of Truth. Smooth management of data: since pilot data will not be maintained in any local copy, there isn't a question of keeping it in sync, ensuring data consistency, and even stale info-related problems in the case of Microservice B. Microservice Independence: Since microservice B is independent, the pilots' information may continue running even if the pilot information were not in a need for constant synchronization or maintenance. Disadvantages Performance: That would then lead to a problem with latency because Microservice B would always have had to make a remote call to Microservice A in order to get any of the pilot information. This would then lead to performance bottlenecks that scale with traffic, as well, when such calls started to happen too often-for example, for every booking and email job. Possible Dependence of Microservice A: Since Microservice B depends on real-time data from Microservice A, if Microservice A becomes unavailable or not real-time in nature, then Microservice B will get impacted. Again, this can be handled by the use of the cache and fallback technique, wherein pilot data can be cached locally for some period. The right thing to do While attaining this balance between these trade-offs, approach 3Store only the pilotId and fetch the data on demand seems to be just right for your application with respect to the following reasons:
No data duplication: He does not store duplicate pilot data-a microservices principle-no single point of truth for any piece of data. Less Management of Synchronization, Updates, or Stale/Inconsistent State: Since you do not rely on data in Microservice A, you do not need to manage synchronization, updates, or risks of stale or inconsistent state between services. Microservices Decoupling: In figure above, microservice B is decoupled less tightly from microservice A. That is a good practice in general for microservices architecture. Scalability: On the performance side, there would be minor issues, since this is an outgoing call to Microservice A, and these can be mitigated by caching (such as pilot information for caches in Microservice B for a limited amount of period) or making this more asynchronously event-driven for purposes such as email sending.
Problem: Performance
If you are expecting high volume bookings and pilot lookups frequently then at least the above reasons do address some of the performance issues which may then arise. Caching : Cache the pilot data in Microservice B or even better some external caching layer like Redis, so that for a time period, say 5-10 minutes, multiple calls are not going to hit Microservice A using the same pilot. Batch/Async: Assume the sending job of emails can tolerate eventual consistency and see if this is possible as a batch job or event-driven approach with pilot details fetched asynchronously or staying in some form of cache for the duration of a job. Overall, Approach 3 best balances maintainability, microservice principles, and flexibility while amply accounting for scalability and data consistency concerns in time.