I need some wisdom on this. Currently I'm learning about micro-services architecture, and so I decided to make a simple project in a micro-services architecture. The project I'm building is just a simple Inventory management application, where the functionality is, well just to add Item and information about it. So at the current state, I have a:

  • Authentication server
  • Item management server

The Authentication server has responsibilities to handle registering a User, changing its password, and exchanging http basic auth to jwt token to be used in Item management server. Item management server is a basic CRUD server for Item.

The way I do this, I create a single database, both server connecting to this database and I have another repo that runs migration on the database that satisfies both servers. Currently I'm using PostgreSQL. Let's say this is the schema:

  - UserTable
    - id ;; UUID
    - username 
    - password
  - ItemTable
    - id
    - owner ;; foreign key to UserTable id
    - name

This article states that using a single database for many apps is bad, because your server is actually tightly coupled to the others through the database. If I'm going to apply this, then I have to change how I work with the database:

  - UserTable
    - id ;; UUID
    - username 
    - password

  - ItemTable
    - id 
    - owner ;; not sure what the type of this, should this be a plain UUID?
    - name

So the question is:

  1. What would be the suitable data type for owner in ItemTable that previously points to user id?
  2. Since I'm no longer using shared databases, for example, if I need to query an Item and I also want to display its owner, does that mean I have to do an HTTP call (assuming I'm using REST) to the Authentication server (assuming the Authentication server is capable of doing this)?
  • Why would the type of the field need to change? Aug 7, 2019 at 3:31
  • In any case, a gateway/backend for frontend might help you. See here and here. Aug 7, 2019 at 3:35
  • 1
    The issue is scalability. What that means is that you don't want services competing with each other for the same data. One way to solve that is by caching the data. Aug 7, 2019 at 14:27
  • 2
    Also, for what it's worth, I don't think you should solve a problem that you don't have yet. If your application requires data from a common source, then your application requires data from a common source. Put a microservice in front of that data, and let the other microservices access it. Or, y'know, use a common database and cache the values. The only way you're going to know for sure is to try it and see what works in your situation. Aug 7, 2019 at 14:28
  • 3
    In my opinion, micro services trades complexity for separation. So your solution will be more complex compared to a monolith. The advantage would be that microservices are independent, so can use different tech, deployed independently, developer needs only needs to be an expert on a single service, etc. Most of these advantages are only relevant for larger systems. And you typically need to be very familiar with the domain to know where to draw the borders between the services. There are some fun horror stories out there about micro services done incorrectly.
    – JonasH
    May 4, 2022 at 8:38

1 Answer 1


A general idea to cut your issues down with the aim of Microservices paradigm would be a strategic pattern of DDD which called context mapping. In the context mapping you define the type of the relations between your bounded context and you shape your domain models which may seem are duplicated in names, though these are different in usage.

For the example that you mentioned, it seems that you have two bounded context, means Item and User. In the Item bounded context (i.e. ItemService) you can specify a reference to your User entity via a username or an id. Here the User entity of the Item context (you can also call it Customer entity) can makes a different sense from the User context. For instance, you don't need the password of the user in Item context. So, you can accomplish an eventual contingency inside the Item context which is updated by User context's events (e.g. a username changed or new user created).

In this scenario, you have your relational databases throughout your application. If you need more data of the User in the Item context, you can simply use a restful api to query the needed data.

The source of truth of the User entity is the User context (i.e. UserService). So the Item context is a gainer not an actor of it. At this point, you have independent services which can own their databases and infrastructures.

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.