0

I am trying to convert one monolithic application into micro service oriented architecture style. Back end I am using spring , spring boot frameworks for development. Front-end I am using angular 2. And also using PostgreSQL as database.

Here my confusion is that, when I am designing my databases as distributed, according to functionalities it may contain 5 databases. Means I am designing according to vertical partition. Then I am thinking to implement inter-microservice communication services to achieve the entire functionality.

The other way I am thinking that to horizontally partition the current structure. So my domain is based on some educational university. So half of university go under one DB and remaining will go under another DB. And deploy services according to Two region (two for two set of university).

Currently I am decided to continue with the last mentioned approach. I am new to these types of tasks, since it referring some architecture task. Also I am beginner to this microservice and distributed database world. Would someone confirm that my approach will give solution to my issue? Can I continue with my second approach - horizontal partitioning of databases according to domain object?

halfer
  • 19,824
  • 17
  • 99
  • 186
Mr.DevEng
  • 2,651
  • 14
  • 57
  • 115

3 Answers3

2

Can I continue with my second approach - Horizontal partitioning of databases according to domain object?

Temporarily yes, if based on that you are able to scale your current system to meet your needs.

Now lets think about why on the first place you want to move to Microserices as a development style.

  1. Small Components - easier to manager
  2. Independently Deployable - Continous Delivery
  3. Multiple Languages
  4. The code is organized around business capabilities
  5. and .....

When moving to Microservices, you should not have multiple services reading directly from each other databases, which will make them tightly coupled.

One service should be completely ignorant on how the other service designed its internal structure.

Now if you want to move towards microservices and take complete advantage of that, you should have vertical partition as you say and services talk to each other.

Also while moving towards microservices your will get lots and lots of other problems. I tried compiling on how one should start on microservices on this link .

How to separate services which are reading data from same table:

Now lets first create a dummy example: we have three services Order , Shipping , Customer all are three different microservices.

Following are the ways in which multiple services require data from same table:

  1. Service one needs to read data from other service for things like validation.

Order and shipping service might need some data from customer service to complete their operation.

Eg: While placing a order one will call Order Service API with customer id , now as Order Service might need to validate whether its a valid customer or not.

One approach Database level exposure -- not recommened -- use the same customer table -- which binds order service to customer service Impl

Another approach, Call another service to get data

Variation - 1 Call Customer service to check whether customer exists and get some customer data like name , and save this in order service

Variation - 2 do not validate while placing the order, on OrderPlaced event check in async from Customer Service and validate and update state of order if required

I recommend Call another service to get data based on the consistency you want.

  1. In some use cases you want a single transaction between data from multiple services.

For eg: Delete a customer. you might want that all order of the customer also should get deleted.

In this case you need to deal with eventual consistency, service one will raise an event and then service 2 will react accordingly.

Now if this answers your question than ok, else specify in what kind of scenario multiple service require to call another service.

If still not solved, you could email me on puneetjindal.11@gmail.com, will answer you

techagrammer
  • 1,291
  • 8
  • 19
  • Yes Sir, Your statements are true. Anyway thank you for your response and spending time with my issue. I already went through database design best practices related with vertical fragmentation along with microservice architecture. I found the same that you added here - creating service independently. But I have one confusion - If my more than one service functionality depending on same tables then how i need to manage that ? my 4 independant functionality taking data from same tables. – Mr.DevEng Mar 07 '18 at 08:42
  • normally it should not happen, if you can give description of table and what your functionalities are will be able to help better??? – techagrammer Mar 07 '18 at 09:17
  • Currently I am analyzing. Need to do that. Let me say my point. Suppose if some table containing data which is commonly using in two different microservice , then CRUD operations will not be synchronized. I have some land survey functionalities. All services are referring my some common tables . So in that case how I can achieve independency? Sorry for not giving actual design .Still I am analyzing for this task .Still making overall idea about service DB management. – Mr.DevEng Mar 07 '18 at 09:54
  • For example - My functionality F1 referring tables T1, T2 , T3. Functionality F2 referring tables T1 , T2 , T4 ,T5. And F3 referring table T1. So each are independant services from one domain. So how I need to create different databases for each functionalities ? . Here I am not disclosing exact project functionality, sry for that. Am I need to implement these 3 end points in one spring boot project with DB containing all tables or as different projects? How this structure will come on scene? , I am facing lot of confusions , since i am new to service world and spring boot. – Mr.DevEng Mar 07 '18 at 11:24
  • Ok sir. Let me check your response. Thank you. – Mr.DevEng Mar 07 '18 at 13:21
  • Yes I got the way of solution. Its calling another service method that you recommended (Another Approach).It will work for my scenario. And aso I will explore the delete customer functionality that you explained. Anyway thank you for your response and spending time with my issues. Thanks. – Mr.DevEng Mar 07 '18 at 13:31
0

Currently I am decided to continue with the last mentioned approach.

If you want horizontal scalability (scaling for increasingly large number of client connections) for your database you may be better of with a technology that was designed to work as a scalable, distributed system. Something like CockroachDB or NoSQL. Cockroachdb for example has built in data sharding and replication and allows you to grow with adding server nodes as required.

when I am designing my databases as distributed, according to functionalities it may contain 5 databases

This sounds like you had the right general idea - split by domain functionality. Here's a link to a previous answer regarding general DB design with micro services.

Oswin Noetzelmann
  • 9,166
  • 1
  • 33
  • 46
0

In the Microservices world, each Microservice owns a set of functionalities and the data manipulated by these functionalities. If a microservice needs data owned by another microservice, it cannot directly go to the database maintained/owned by the other microservice rather it would call an API exposed by the other microservice.

Now, regarding the placement of data, there are various options - you can store data owned by a microservice in a NoSQL database like MongoDB, DynamoDB, Cassandra (it really depends on the microservice's use-case) OR you can have a different table for each micro-service in a single instance of a SQL database. BUT remember, if you choose a single instance of a SQL Database with multiple tables, then there would be no joins (basically no interaction) between tables owned by different microservices.

I would suggest you start small and then think about database scaling issues when the usage of the system grows.

Kanishk
  • 401
  • 3
  • 6
  • Thank you for your response sir. If I am fragmenting DB vertically , then it will suite properly to achieve the actual benefit of micro service oriented architecture. But In my scenario , my more than one functionality taking data from same tables. So if I am choosing that DB for different service, CRUD operation will not be synchronized , since I am taking same DB for more than one independent service . So In these situation how I need to manage my DB fragmentation and service designing? Can you please check my points what I mentioned in these statement ? – Mr.DevEng Mar 07 '18 at 08:54
  • Basically, a partial reason to have a separate DB for each micro-service exactly is due to the problems when you have multiple writers. There would be fewer problems if only 1 micro-service can change data in that table. There is no problem in reading the data from these tables by other micro-services (but you would definitely lose the benefit of loose coupling). Nothing is stopping you to read data directly from the tables owned by other micro-services but the preferred way to access that data is through that data owner's APIs. – Kanishk Mar 08 '18 at 07:01
  • If you still want to by-pass the API route and read data directly, another way is to have some duplication by maintaining multiple tables (multiple sets) of the same data (where you don't need to worry about synchronization. Each write transaction will update all the duplicate tables simultaneously). Each Micro-service will maintain its own set of data it is interested in. Write would happen through only 1 micro-service but data would be updated in all the tables simultaneously. – Kanishk Mar 08 '18 at 07:01