I have a Custom REST Activity. When I activate a Journey with my activity for a large number of clients (DE entry) what are the requirements for MyAPI?
el-niko,
There's no hard limit to the number of requests you could receive, but there are limitations and bottlenecks in Journey Builder's backend processing that effectively cap the total number of requests you can anticipate. My understanding is that currently the maximum throughput is around 2 million contacts processed for injection per database instance per hour. You may or may not be on a dedicated database instance. If on a shared instance, this 2 million injections per hour will be shared with other tenants sharing the database with you.
There are a few levers you can use throttle requests to your endpoint that were added a year, or so, ago. In your arguments.execute object in your config.json, you can state the maximum number of concurrent requests made to an instance of your activity, maximum number of retries of soft errors and the delay that Journey Builder should wait before retrying failed requests to your activity.
Further details relating to configuration of your config.json can be found in Developer Documentation Custom Activity Configuration and a very useful video to take a look at that describes some best practice for building a Custom Journey Builder Activity is shared in TMM Journey Builder Custom Activities (start from 26:42 in).
My recommendation would be to take a look at why you are trying to throttle Journey Builder and architect your application to avoid this. Even at low levels of concurrent requests, Journey Builder's behaviour is quite "bursty". So, I'd consider using a design that will scale to meet Journey Builder, rather than try to slow down Journey Builder to meet your application. Take a look at implementing serverless functions like Lambda to handle requests and processing. They'll scale infinitely. Implement a queueing solution that can handle slow processing downstream from the request being made. Consider carefully where you host your application. If it's making a lot of API calls to SFMC, park it a location with low latency connections to your SFMC stack. If the application's making large volumes of requests to some other third party API, choose somewhere with low latency connections to that API. Use a fast cache to keep data that's frequently accessed by your application, avoid as much synchronous processing as you can while the execute route is being handled and return 200 OK as quickly as you can to Journey Builder.
