Technical design: Automated greeting on an online procurement website

Let's create a basic technical design for an online procurement website. The website caters to millions of purchasers who are searching for suitable suppliers. Purchasers can share their procurement requirements along with all the necessary details, and suppliers can submit their products for consideration. On the purchaser's user interface (UI), they can view the suppliers who have applied and decide whether they want to proceed with these supplies (i.e., bookmark them) for the next steps. Now, the website aims to provide purchasers with an automation option: purchasers can give the website permission to send automated greeting messages to the bookmarked suppliers on their behalf.

Considering the product requirements, the website should offer an opportunity for purchasers to opt in. Once purchasers choose to enable the new automation feature, the website can begin sending greeting messages to newly bookmarked suppliers. To prevent accidental clicks and messages, there is a 10-minute waiting period after the purchaser bookmarks the supplier before the message is sent. In order to facilitate analysis of the new feature, the data scientist also desires to obtain the timestamp indicating when the greeting messages were sent.

The website employs a micro-service architecture and already incorporates services such as the purchaser service, which utilizes a database to store purchaser-related data, the supplier service, which uses a database to store supplier-related data, and the messaging service for sending messages. Suppose you are the software engineer tasked with implementing this feature, how do you plan to design it?

It's quite straightforward to store the purchaser opt-in data in the purchaser-related database through the purchaser service and store the timestamp through the supplier service follow a similar approach. When it comes to sending greeting messages with a 10-minute delay after purchasers bookmark certain suppliers, there are multiple options to consider.

One commonly used approach is to create an API that handles the scheduling and sending of messages. This API is called immediately after the bookmark action occurs. If the bookmark action is initiated by a button, the API call is triggered behind the scene when the button is clicked.

Another solution is to produce and publish events for the bookmark action. These events include important data such as the purchaser ID, supplier ID, bookmark action (bookmark or rescind), and other relevant information. By doing this, multiple consumers can subscribe to, consume, and process the same event, each dealing with different logic. This approach enhances scalability and flexibility.

An important aspect of the design is determining how to schedule a 10-minute delay before sending out the message. Common approaches, such as Kafka and RabbitMQ, can accomplish this, but they require manual efforts to set up the schema and pipeline. Alternatively, workflow tools like Temporal and Cadence simplify and expedite the entire implementation.

The final design, utilizing the event consumer approach, with the Temporal workflow tool, is as follows: