CODEWITHSUNDEEP
databasemicroservices
abrarisme
abrarisme

Reputation: 495

How should we structure our models with microservices?

For example, if I have a microservice with this API:

service User {
    rpc GetUser(GetUserRequest) returns (GetUserResponse) {}
}

message GetUserRequest {
    int32 user_id = 1; 
}

message GetUserResponse {
    int32 user_id = 1;
    string first_name = 2;
    string last_name = 3;
}

I figured that for other services that require users, I'm going to have to store this user_id in all rows that have data associated with that user ID. For example, if I have a separate Posts service, I would store the user_id information for every post author. And then whenever I want that user information to return data in an endpoint, I would need to make a network call to the User service.

Would I always want to do that? Or are there certain times that I want to just copy over information from the User service into my current service (excluding saving into in-memory databases like Redis)?

Upvotes: 1

Views: 125

Answers (2)

techagrammer
techagrammer

Reputation: 1306

Copying complete data generally never required, most of times for purposes of scale or making microservices more independent, people tend to copy some of the information which is more or less static in nature.

For eg: In Post Service, i might copy author basic information like name in post microservices, because when somebody making a request to the post microservice to get list of post based on some filter , i do not want to get name of author for each post.

Also the side effect of copying data is maintaining its consistency. So make sure you business really demands it.

Upvotes: 1

Oswin Noetzelmann
Oswin Noetzelmann

Reputation: 9545

You'll definitely want to avoid sharing database schema/tables. See this blog for an explanation. Use a purpose built interface for dependency between the services.

Any decision to "copy" data into your other service should be made by the service's team, but they better have a real good reason in order for it to make sense. Most designs won't require duplicated data because the service boundary should be domain specific and non-overlapping. In case of user ids they can be often be treated as contextual references without any attached logic about users.

One pattern observed is: If you have auth protected endpoints, you will need to make a call to your auth service anyway - for security - and that same call should allow you to acquire whatever user id information is necessary.

All the regular best practices for API dependencies apply, e.g. regarding stability, versioning, deprecating etc.

Upvotes: 1

Related Questions