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: D

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.

  • By "business", you mean "company", not "business area", I guess?
    – Doc Brown
    May 26, 2023 at 8:41
  • This looks like a form of CQRS May 26, 2023 at 14:22

1 Answer 1


There is nothing special when a search service 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, knowing 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.

  • Oh wow that's a very awesome reply. First of all, thank you for criticizing my design, I feel much better now that I know at least my idea of a well-structured design, is not so far-off. Secondly, your last suggestion really got me thinking. It's definitely an interesting thought, I guess you could use one table for them but it's best to partition the tables for records which are "businesses" and records that are "single person" (I guess?). Trying to accommodate high QPS. May 27, 2023 at 8:31
  • @AndrewSharifikia: I did not wrote "one table": I wrote "one service".
    – Doc Brown
    May 27, 2023 at 8:32
  • Yeah, that'd be great. Thanks again! May 27, 2023 at 8:33
  • @AndrewSharifikia: modeling of parties usually involve three tables: one for persons, one for organizations, and one for the commonalities. That's a well know analysis pattern, see martinfowler.com/apsupp/accountability.pdf, page 5.
    – Doc Brown
    May 27, 2023 at 8:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.