How to handle input validation in microservices for duplicated data

Question

What would be the best practice of handling input validation in microservice? Especially for the duplicated data?

To give context, say I have 3 services:

User

Typical user service with User object with a lot of details (~40 fields in the object)

Asset

Has Asset object like

{
  id,
  name,
  companyId,
  descripton
}

News

News service has a Feed object that have reference to both User and Asset however for News it only care subset of both User and Asset fields (ie. only need 10 of User field)

{
  id,
  title,
  description,
  asset,
  user

I'm aware of the concept that News should have its own view of User and Asset and data consistency can be done through message hub. So the question now becomes if I have an http post request for new feed so the request body looks something like

{
  "title": "title",
  "description":"description",
  "asset": {
    "id": "asset1",
    "name": "phone",
    "companyId": "company-1"
  },
  "user": {
    "id: "user-1",
    "name": "name",
    "comapnyId": "company-1",
    "roles": ["reporter"]
  }
}

How should I perform the input validation for both user and asset field in News service? Say the input validation for user is something like:

• user role can't be mix of reporter and manager (either one)
• name < 120 char
• companyId must be null if user role is a client, otherwise it must be set

Should I then have this input validation sits in both News and User service? Using a common/shared object with validation seems simpler but I always thought it's kind of antipattern or am I missing something here?

PS - I tried to avoid direct service to service call (also client can't perform multiple requests due to limited network bandwidth) so just storing assetId and userId in the Feed won't work

PSS - the backend code is written in Go so OOP approach may not be best suited

Answer 1

As is already visible from the comments, there is neither an easy nor an ideal way. It all depends on your application and your requirements.

Nevertheless, an approach that might be possible for your system is, that the news service passes validation requests on to the user service and asset service when a new news object is created. So, when you receive the post in your example, news service asks user service: "hey, someone says he has userid-1, name 'name', and company 'company-1' - is this ok and can that person create news?". If the answer is "OK", then store the fields you need, but do not depend on the user service every time someone reads that object.

If the user service is down, you'll need some kind of backup strategy. You might store the object as a "request" and decide when the user service is up again, or simply retry a given number of times before reporting failure. Note that in a productive live environment, "down" usually means that the monitoring system is already aware of the problem and in the process of restarting the service. Therefore, "down" is a condition over a few seconds at most.