Backpressure

Backpressure is a common problem in Pub/Sub systems. It happens when messages are being published to a queue faster than they can be consumed. This leads to a growing queue size, which can eventually cause the system to run out of memory or disk space.

Assignment

Let's add a feature to spam absurd amounts of game logs... for science. We'll use this feature to demonstrate backpressure.

In the src/client/index.ts file, in the main function, update the section of code that handles the spam command. It should now:
1. Ensure that a second "word" was provided in the command. E.g. spam 10 or spam 1000. Convert that word into an integer.
2. Do the following n times, where n is the integer from the command:
  1. Use the getMaliciousLog function in src/internal/gamelogic/gamelogic.ts to get a malicious log message.
  2. Publish the log message (a struct) to Rabbit. Use the following parameters:
    1. Exchange: peril_topic
    2. Key: game_logs.username, where username is the username of the player

Because our game_logs queue is listening for messages with the routing key game_logs.*, the server will receive messages from all players.

Update the subscribe<T> function in the src/internal/pubsub module, after calling declareAndBind, add the following line:

await ch.prefetch(1);

This tells RabbitMQ to only deliver one unacknowledged message at a time. It waits for an ack before sending the next one. That way, the server processes messages strictly one at a time, and we can finally see the queue grow. (We will dive deeper into ch.prefetch in an upcoming lesson.)

Test the new code.
1. Start a server and a client. Open the web UI to the game_logs queue screen.
2. Use the client to spam 25 log messages.
3. Notice how in the web UI you should see a spike in queued messages. Notice that the server can only process one log per second, after 25 seconds, you should see the queue empty out.
4. Publish another 10000 logs.
5. Again, you'll see a huge spike, but this time it's going to take too long to wait for...

After publishing a large batch, refresh the page before running or submitting the tests to make sure the queue metrics were updated.

Run and submit the CLI tests with the queue still mostly full (thousands of messages).

In the next lesson, we'll empty the queue.

Troubleshooting

If messages_ready is set to 0, try any of the following:

Stop the server so that messages are not consumed.
Restart the rabbitmq container. Make sure the peril_direct and peril_topic exchanges are there (they should be if you use the npm scripts) and restart the server to create the game_logs queue.