can we agree on naming primary keys as {tablename}_id? that way it would be consistent throughout the database and it is always clear what the id refers to and you can even select like this:

SELECT * FROM vote JOIN user USING (user_id)

Updated the ids to have the pattern mohs8421 suggested.

Fleshed out other tables and added comments where appropriate.

you did two small copy-paste errors along the way: USER_METRIC_ID and STATEMENT_METRIC_ID

Report data should be tied to a report record that specifies the timestamp the report represents.

Add in a report table that has

• The timestamp the report ran at.
• The algorithm used.
• Plugin identifier.
• The input parameters for the plugin.
• The Poll ID

Math Server 1 (at math1.voxit.com) Meth Server 2 (at math2.voxit.com)

The both listen to the queue When their down they send a message through the bus with their identifier and results. We send the results directly to client. Then another service pushed into the db.

A message bus delivers notifications about new statements, updates results or new report data.

The API server(s?) for the participation and reporting UI should listen for relevant updates and push updates via SSE to the connected clients. Plugins/Addons can also make use of these notifications.

The notification service which sends notifications to participants (e.g. via email, social media posts) will not use this since it does not updates in real time but needs to determine whether there have been changes over a user-configured time interval (e.g. send out a message if there have been new statements since the last notification). It can do so by recording the timestamp the last notification of a certain type was sent out for a certain conversation.