Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to perform validation across services in microservices

Suppose there are two microservices: Order and Inventory. There is an API in order service that takes ProductId, Qty etc and place the order.

Ideally order should only be allowed to place if inventory exists in inventory service. People recommend to have Saga pattern or any other distributed transactions. That is fine and eventually consistency will be utilized.

But what if somebody wants to abuse the system. He can push orders with products (ProductIds) which are either invalid or out of inventory. System will be taking all these orders and place these orders in queue and Inventory service will be handling these invalid order.

Shouldn't this be handled upfront (in order service) rather than pushing these invalid orders to the next level (specially where productId is invalid)

What are the recommendations to handle these scenarios?

like image 469
Pragmatic Avatar asked Feb 17 '18 05:02

Pragmatic


People also ask

How do I add validation to API?

To enable a request validator on all methods of an API, specify an x-amazon-apigateway-request-validator property property at the API level of the OpenAPI definition file. To enable a request validator on an individual method, specify the x-amazon-apigateway-request-validator property at the method level.

What is validation in API?

Validation can mean a lot of things, but in API land it generally means figuring out if the data being sent to the API is any good or not. Validation can happen in a lot of different places - it can happen on the server, and it can happen in the client.


1 Answers

What are the recommendations to handle these scenarios?

Give your order service access to the data that it needs to filter out undesirable orders.

The basic plot would be that, while the Inventory service is the authority for the state of inventory, your Orders service can work with a cached copy of the inventory to determine which orders to accept.

Changes to the Inventory are eventually replicated into the cache of the Orders service -- that's your "eventual consistency". If Inventory drops off line for a time, Order's can continue providing business value based on the information in its cache.

You may want to be paying attention to the age in the data in the cache as well -- if too much time has passed since the cache was last updated, then you may want to change strategies.

Your "aggregates" won't usually know that they are dealing with a cache; you'll pass along with the order data a domain service that supports the queries that the aggregate needs to do its work; the implementation of the domain service accesses the cache to provide answers.

So long as you don't allow the abuser to provide his own instance of the domain service, or to directly manipulate the cache, then the integrity of the cached data is ensured.

(For example: when you are testing the aggregate, you will likely be providing cached data tuned to your specific test scenario; that sort of hijacking is not something you want the abuser to be able to achieve in your production environment).

like image 147
VoiceOfUnreason Avatar answered Oct 13 '22 19:10

VoiceOfUnreason