3

I'm designing an application in a micro-service architecture and I have some questions regarding error codes.

Found some information about it (1,2) - but more focused on the responsibility of the error code management.

Suppose I have 2 micro-services and an API Gateway. At current design - each micro-service is defining it's own error codes with a define prefix where there are 2 types of errors:

  1. General Errors
  2. Fields Validation Errors

For example:

Projects Micro Service Error Responses:
{
  "status": 1,
  "error": {
    "error_code": "a_133",
    "error_str": "project not exists"
  }
}

{
  "status": 1,
  "error": {
    "error_code": "a_2",
    "error_str": "invalid parameters",
    "error_fields": {
      "project_name": "project name is too short",
      "project)date": "invalid date format"
    }
  }
}

Billing Micro Service Error Response:
{
  "status": 1,
  "error": {
    "error_code": "b_243",
    "error_str": "billing validation was failed"
  }
}

Every "create" endpoint that is created in Projects or Billing Micro services should be handled also in the GW - where this micro-service is usually forwards the requests after authenticating the user.

My question is how it should handle the error codes? Should it forward the errors he got from the micro-services or it needs to translate them into his own set of errors? making a lot of conversion code - specially when dealing with "Fields Validation Errors".

What's the best practice here?

  • If the gateway can handle the error then it should, otherwise it should simply forward it to the client. – Dan Wilson Jun 24 at 6:06
  • He always can handle the error - but it will require a lot of boilerpate code - the question is what is usually done on the parameters validation side? – sborpo Jun 25 at 4:04
  • 1
    My response would apply to field validation errors as well. Let each service respond with its own field validation error messages and simply forward them to the client (no translation). The back-end service is the authority on what it requires, not the gateway. Any translation by the gateway is asking for difficult-to-troubleshoot issues when the service is updated but the gateway is not. – Dan Wilson Jun 25 at 15:12
  • You might get better answers with a more detailed use case than service A and service B. – Dan Wilson Jun 25 at 15:48
  • Changed the names, isn't this breaks system encapsulation? or may expose "private" error codes of the inner micro-services? – sborpo Jun 26 at 10:14
1

In my opinion if you want to follow the smart endpoints and dumb pipes principle than you should not put too much logic into your API gateway. You should consider it as a facade in front of your microservices or a reverse proxy and not as a 'yet another adapter'.

But as always it depends. Here are some examples when it could make sense to hide / translate some of the error codes

  • If for instance your API's consumers are concerning every error as a show stopper then differentiating different errors outside your gateway boundary does not add too much value.
  • If your microservice error code refers to a field which is added automatically to the request by the API gateway on the requester's behalf, like Correlation Id.
  • If the error message / code reveals some implementation details. For example instead of saying "the mailing provider is currently unavailable" you would say "mailchimp servers are currently unavailable".
| improve this answer | |

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.