Optimal choice of architecture for event notification functionality

[Lepiloff]

Hi there! I want to add a simple notification system for incoming requests to the app.

Business logic:

• user1 creates an event (offline party)
• user2.....userN sends a request to participate in the event (not at the same time, but during the validity period before the event)
• user1 logs in on the site and receives notification of received orders. Processes them (rejects or accepts)
  All N users can create events and take part in them. The total number of service users > 10k. But in a specific event, the maximum number of participants is 50.

There was a choice of appropriate technical implementation of such functionality. Searching the information on the Internet I identified 3 main approaches:

• message broker (rabbitmq)
• websocket
• SSE (Server Sent Events)
• maybe something else?

How I see the implementation:
To send a request for participation in the event, a standard post request is used, as a result of which the corresponding record is created in the database

The part that I don't understand at all is the notification of the creator of the event about the requests received.As a variant I assume to use middleware, inside which will be the logic to check for new requests (the question is what to use inside the logic).
It is not necessary to get information immediately online, it is enough to see the notification when the browser page refreshes.

In fact, it is possible to add in the middleware query to the database to check for new records. But this is exactly what I want to avoid. I'm looking for a way to query the database only if there's actually new information there.

Any thoughts and advice are welcome

[STeveShary]

@Lepiloff This is a very broad question and there are many different options. I can share some thoughts and how FastAPI might fit in with those. It does sound like you have a 1 to many notification scenario that you want to complete.

First, try and use the simplest approach. Use fast API with a database and store messages and the receipt of messages in a Postgres/Mysql database. You can have your clients use a simple long-polling: https://javascript.info/long-polling. This follows the KISS scenario. You might be surprised how well this performs and scales.

Second, you can use a service that does this for you! I have professionally used pubnub (https://www.pubnub.com/) for this and it works well.

Lastly, whichever solution that you choose, make sure you understand the threading model. FastAPI can scale tremendously when there are asyncio libraries to use with it. If you choose a blocking library, you will find that your performance drops rapidly.

Best of luck!

[Lepiloff]

@STeveShary Thanks for the reply. I have now decided in favor of storing events in a database and accessing them via standard http requests. I will take a closer look at pubhub service, maybe this is exactly what I need in the future.