2

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:

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

MyUserDb:
  - UserTable
    - id ;; UUID
    - username 
    - password

MyItemDb:
  - 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? – Robert Harvey Aug 7 at 3:31
  • In any case, a gateway/backend for frontend might help you. See here and here. – Robert Harvey Aug 7 at 3:35
  • @RobertHarvey Hi, thank you for responding. Because based on the article given at my post and also this one, having a single database across the entire micro-services is considered an anti-pattern and I don't have any experience to deny that claim. So based on that, if I want to use single database per service, how do I describe that owner in ItemTable points to id in UserTable? I am under the impression that I can't use foreign key cross databases (PostgreSQL). – autumn322 Aug 7 at 9:29
  • Each Microservice should indeed be responsible for it's own data. If a request comes in at microservice A, microservice A should not query microservice B. If B depends on data from A, whenever data in A is changed it should generate an event which B can react to to duplicate the data. – Rik D Aug 7 at 11:54
  • 1
    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. – Robert Harvey Aug 7 at 14:28
0

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, privacy policy and cookie policy

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