Synchronous Personalization

In 2020 we made a spike together with personalization team about delivering personalised in-app messages without having to pre-generate the messages like other channels to. This spike used a new synchronous REST endpoint which would be easy to use from a service like the Device Event Service when serving in-app messages to devices.

Problem

Recently we were made aware of the fact that this endpoint would be delayed quite significantly and we will need to use the upcoming v3 API of the personalization service. The v3 is based on pubsub for the actual compilation of templates.

We need to come of up with way to use the new interface from the synchronous endpoint serving messages in Device Event Service.

Requirements

  • Use the Google PubSub based interface of the personalization service

  • Use synchronous events endpoint when serving messages.

Proposal

Introduce a new REST service which solves the problem of synchronising the Google PubSub interface using Redis.

We’ll create a compatible REST interface so that we can use the current integration in DES. The only relevant endpoint that we need to provide is the compile endpoint which is in the context of a customer, a campaign and a template and accepts the contact-id as part of the payload.

Workflow

  1. Accept request

  2. Generate a request-id based on the template hash and a uuid and subscribe to it in redis.

  3. Publish Compile Request to PubSub

  4. Wait for Promise with the result

  5. A PubSub-worker consumes the results from the subscription and publishes to Redis

  6. The web-worker receives the result from Redis and resolves the Promise.

  7. The request is finished.

Slow responses

Since the service is made specifically for In-app messages we can timeout messages that needs longer than 1-2sec to be processed by the personalization service.

Prototype

To test the feasibility of using Redis in this way I created a small prototype which build the workflow described above.

Testing performance

Doing a quick performance test locally by sending 1000 requests using httperf revealed that PubSub is adding quite a bit of overhead and that the Redis PubSub is performing quite nicely. It should of course be noted that these tests were all run locally and results would be very different running in Google Cloud.

Including PubSub

Test using the full workflow including going via PubSub.

Request rate: 1.8 req/s (555.0 ms/req)

Excluding PubSub

Test excluding PubSub so instead of publishing to PubSub the result was published directly to Redis. The step which is usually done by the worker when receiving the message from PubSub.

Request rate: 286.4 req/s (3.5 ms/req)