At the moment, I'm working on a product that's being broken down from a monolith to a bunch of microservices, and it seems to be going well enough.

However, if a user is abusing the service somehow, we're not sure how to leverage that information to block the user. For security reasons, we don't pass (for example) IP address from client-facing services to internal services. For request tracing purposes, we do pass the request ID and generate span IDs, so we can identify the request.

So, we have a service deep in the stack that has identified an incoming request is abusive (or potentially abuxsive). We have the caller service way up the stack who can resolve request ID to surrounding context. And we have a bunch of internet-facing service nodes that we need to propagate information out to along the lines of "requests that come in with the following context should be blackholed / tarpitted / errored out".

There are, of course, a lot of different ways we could solve this problem. We could have something triggered in the monitoring / log aggregation which pushes abuse handling configuration out to internet-facing hosts, we could have a "UserAbuse" error type that propagates up the RPC stack, or a separate service that- as soon as an issue is detected- gets called with the abuse info, and that service also somehow resolves request IDs to context information.

My question is just "what have large, successful companies done to solve this problem?". What are some design patterns we can try to apply?

  • Why don't the public-facing services ask the abuse-classification service whether a particular request should be granted or blocked? Why the need for pushing this info elsewhere? For example, are your public-facing servers geographically distributed so that latencies make this infeasible? – amon Jan 23 at 19:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.