Chapter 4: Pace the calls with a rate limiter

In Chapter 3 a single run fanned out up to 100 downstream messages at once. Real APIs cap how fast you may call them, so now you'll import a topology that paces that same fan-out with the platform Limiter.

By the end you'll be able to throttle a whole flow to a safe rate without writing any code.

Prerequisites #

Nothing new to set up. Reuse the pieces from the earlier chapters: the mock server is running and the Products Test (Simulation) application is installed, authorized, and active.

What's new in this chapter #

Limiter. A keyed throttle the platform applies between your worker and the rest of the system. You configure it as pure application settings (no code), and the platform paces every app-bound node automatically, including the connector that runs after a batch fan-out. When the rate is reached the surplus messages are held and drain over time (backpressure), rather than failing. Background: Rate limiting.

The topology reuses the batch from Chapter 3 and adds a tiny mapper (products-test-extract-id) that trims each listed product to { id }, so the products-test-get-product connector can re-fetch it one by one. That per-item connector is what the Limiter paces.

Import and run #

Import demo-limiter.tplg.json from the demo worker's src/topologies/ folder, then Publish and Enable it.

Turn the Limiter on for the application (this is the whole point of the chapter):

1. Open the Products Test (Simulation) application and go to its Limiter tab.
2. Enable Use limit and set a low rate for a visible effect, for example 10 requests per 60 seconds, then Save.

Now trigger the topology manually from the Cron node. Send nothing to process the full default catalog (100 products), or pass a small cap for a quicker run:

{ "maxProducts": 50 }

The batch pages through the catalog and fans out one message per product, but the connector no longer runs them all at once: it fires at the configured rate while the rest wait their turn. The application's Limiter view shows how many messages are queued and an estimated time to drain.

Where next #

So far every topology started on a schedule or a manual run. In Chapter 5 you'll import the demo-webhook topology and start a flow from an incoming event instead, using a Webhook trigger.