Overview

MIBS is short for "message in a bottle service". The MIBS will be responsible for the handling of "message in a bottle" content.

Design

Technology

• Python 3.9
  • Flask:
    • Will be used for the routing of HTTP requests.
  • SqlAlchemy:
    • Will be used to interact with the database through Python models.
  • Flask-OIDC:
    • Will be responsible for validating access tokens provided in requests.
    • https://flask-oidc.readthedocs.io/en/latest/
    • The OpenId Connnect provider is a Keycloak server.
• Nginx:
  • Will be used to deploy the Flask application using uWSGI.
  • The built in flask server is not suitable for production. https://flask.palletsprojects.com/en/2.0.x/deploying/
• Docker:
  • The service will be deployed as a docker container.

Technical Requirements

• The MIBS will be a docker container.
• The MIBS will be deployed with docker-compose.
• The MIBS will have build in redundancy through scalability.
  • The MIBS must be scalable.
• All requests to the MIBS will be proxied through the reverse proxy to the MIBS.
  • The MIBS receive http requests on port 80.
  • The MIBS will expose port 80 to the default network created by docker-compose.
• The MIBS will verify user authentication through the use of OpenId Connect access tokens provided by Keycloak.
• MIBS messages must support unicode.

API

API File

Database Schema

MIBS-Database.drawio.png

Notes:

• Timestamps will all be stored as UTC time.

MIB Flow

MIBs will be created by the client and sent to the the MIBS by first sending a HTTPS request to the reverse-proxy which will then proxy the request over HTTP to the MIBS in the internal docker network. The MIBS provides HTTP methods to get, create, update, and delete MIBs. The client will use these methods to to manage MIBs for the user.

The MIBS will create a MIB for a user and persist it in the PostgreSQL database according to the database schema outlined under Database Schema. The MIBS will periodically poll the Message table for any unsent MIBs (send column is false with a sendTime and if the lastSentTime exists, 5 minutes must have past since the lastSentTime). During this poll it will update the lastSentTime for every matching MIB to the current time so that another MIBS system does not attempt to send a duplicate MIB to the recipients. The query and the update must an atomic operation so duplicate message are not sent if more than 1 MIBS attempts to query the Message table

Once the MIBS has determined which MIBs it will attempt to send it will resolve the recipients for each MIB by selecting all rows that have a matching messageId between the Message Table and EmailMessageRecipient, SmsMessageRecipient, and UserMessageRecipient (will be referred to as (Email|Sms|User)MessageRecipient for future references) tables and a sent value of false for the (Email|Sms|User)MessageRecipient tables. For each recipient the MIBS will send the MIB to the recipient with respect to it's delivery method. I.e if the recipient is a EmailMessageRecipient then the MIBS will send a message to the recipient by email (SMTP) using the email address specified by the EmailMessageRecipient row. If a message is successfully delivered, the sent column for the (Email|Sms|User)MessageRecipient shall be set to true.

If the MIBS is successful in sending the MIB to all recipients, then the sent column in the Messages table shall be set to true.