Domain Boundary Definition in `proximity service` as a Case Study

Question

While practicing System Design, I decided to create a hypothetical proximity service (like Google Maps) with a microservice architecture. Suppose we have 3 core categories of functionality:

1. CRUD operations for new Businesses (Stores, Restaurants, etc.)
2. CRUD operations for users
3. Search for and retrieve a list of Businesses in an area based on geospatial data

I decided to design the following services:

1. A Data Domain called users_service handling operations related to users
2. A Data Domain called businesses_service handling operations related to businesses
3. A Business Domain called search_service handles the search operation, which basically needs read-only permission.

All constitute together the following diagram that I created:

---

Now my question is:

Is it a good idea to supply a Business Domain with its own Read-Only replicas of Users and Businesses? What's my alternative? I don't want to leak the complex business logic of searching into the businesses Data Domain, but the searching operation needs access to the location of the businesses and needs to perform SQL queries to do so.

Any related comment is welcomed.

Answer 1

There is nothing special when a search services creates a replica or cache of the source data they make available for searching, in a way which is optimized for this purpose. Any search index is such a replica. Full text search engines like Lucene do this. And - obviously - search engines like Google or Bing cache a huge amount of the indexed data from various sources as a read-only copy.

The only thing you have to be aware of is a certain time lag between an update of your source data and an update of the cache.

So I don't see anything obviously wrong with this approach.

You might ask yourself if separating companies/organizations ("businesses") on one hand, users at the other is really what you need. Both terms describe legal persons, with a lot of commonalities, and when your only processes around them are those CRUD services, I think it is at least worth a second look if separating those into different microservices is really necessary. But this can only be answered by having some more real-world context at hand, what other processes you have and if those work separately and differently for users and companies. Still having a separate search cache and or index can make sense.