Let me know your thoughts.

Great points. Agreed…the central database option definitely seems to be the best in terms of performance and complexity. One way, maybe, to preserve some separation of concerns is to enforce some access rules at the DB level to, say, only allow read access to the Customer service, but not write access.

And good point about staleness being an issue not just with the caching option, but also with the n+1 (especially since global transactions aren’t all that viable in SOA, so while orders are being retrieved for n customers, new orders could be coming in).

In one scenario, I have a central database, which I’m guessing is going to occur the lion’s share of the time this problem presents itself. In this case, a simple join of the two tables was all it took. I understand the tight coupling of the two services, but there are always going to be tradeoffs in any solution and obviously the correct approach is contingent on the circumstances of the problem. In this instance, a little tight coupling in my opinion is far better than the n+1 performance issue. I attempted the solution incorporating n+1 and the time it took was exponentially higher.

In the other scenario, we have more of an According-to-Hoyle SOA environment in that one set of data resides in a different repository from another set. In this instance, caching seems to be a viable option. The configuration overhead might be an issue (albeit slight in my opinion) as would staleness, but you run the risk of staleness in any scenario, the only variable is how stale are we talking.

For instance, if I go with a n+1-esque scenario or even the common service that pairs both together, by the time this logic completes, the data could be completely invalid anyway. n+1 as I’ve said is an insane performance hit and a common ‘matching’ service dictates that essentially ALL orders be retrieved, since you have no way of applying additional customer criteria to the order table. In my mind, the solution that makes the most sense is always the one that offers high performance gains while at the same time keeping some level of maintainability and minimal overhead. Mr. Obvious, I know, but people do not always think that way.

Also, I do not think the granularity of these services is far off by any means. This is a perfectly acceptable level of granularity and is very similar to many I’ve run across.

Cool posts, Ben. Love the website too, keep up the good work. Hope all is well.

Ariel - good point…the example is a bit fabricated, so in the real world, two such services might not make sense if these were indeed the requirements. In general, however, I believe the problem is general to most service oriented architectures - most likely you will encounter a requirement that necessitates the merging of data across services.

Ryan - good catch! This is a fifth solution, however, it seems like it too would some performance impact, and also be fairly cumbersome from an implementation perspective - since the “join” logic would need to exist in your application code rather than your database. Your first query would return a set of customers. Presumably, your second query would then use the customer IDs from the first query in the WHERE clause (like “WHERE customer_id IN (1, 5, 23, …)”) and find all the orders associated with those customers. The business tier, then, would be responsible for merging the orders lists with the customer list, which could hurt performance (and maintainability).

Chris - agreed that local caching is typically the best option for performance and perhaps complexity, but like you said, the costs of implementing this are non-trivial and there are big decisions to make (e.g. cache in memory in or in database?, is staleness an issue?, how to implement the pub-sub mechanism?, etc.)

Todd - A service layer like this could work, especially if there are big reuse opportunities. Good point about the batch interface.