mc ab68be9db2
Some checks failed
Build and Push Docker Image / build (push) Failing after 32s
Build and Push Docker Image / docker (push) Failing after 7s
Update README.md
2025-07-05 16:35:58 +00:00
2025-07-05 05:41:38 +02:00
2025-07-05 18:02:25 +02:00
2025-07-05 18:01:39 +02:00
2025-06-28 22:29:46 +00:00
2025-07-05 05:55:21 +02:00
2025-07-05 18:18:54 +02:00
2025-07-05 18:18:54 +02:00
2025-07-05 16:35:58 +00:00

messengerbroker

"send me a tip" "see my github"

An add-on service for Messenger API that adds inter-broker capability, making Messenger API resilient against outage. Runs as sidecar container with it's own DB, and periodically syncs Messenger databases between different instances to provide fallback capability for clients.

Messenger Broker is in alpha. It is discouraged to rely on it in production environment.

Why

Running single instance of message broker mean clients are left with no communication if the instance goes down for any reason at all. Adding secondary, or even tertiary instance of messenger to provide fallback option for clients is desirable. Broker runs in the background as a synchronizer of Messenger API databases. Messenger itself is completely unaware of this, while Broker keeps track of what entities injected into Messenger's database are foreign.

How

Broker runs 3 tasks endlessly for each server it's supposed to provide resiliency for:

  • User and UserRoute synchronization periodically (typically every 1 minute).
  • Message synchronization (fast) - endless queries to provide all messages for last short period of time (typically last 10 seconds).
  • Message synchronization (slow) - endless queries to provide all messages for entire visible history of garbage collection. This process runs typically every 10 minutes and serves to collect missed updates, deliveries, and acknowledgements.

To prevent clogging, Broker will only provide 1000 records per request, so synchronizing Broker has to provide a time argument for where to start the lookup. You can see this here.

Auth

Broker uses it's own unique Broker ID to authenticate itself and others. All exposed endpoints expect this ID to be sent over as part Bearer token in Authorization header. Each Broker is configured for a list of servers that are expected to pull, and list of server that the Broker itself is supposed to pull from. Bearer token is then compared against that list during each call to make sure only allowed Brokers consume resources.

Setup

Mandatory tunables are super-simple:

  • SQL_CONNECTIONSTRING

    • Must be provided. This is Broker's own database.
    • Example: "Persist Security Info=False;User ID=*****;Password=*****;Initial Catalog=AdventureWorks;Server=192.168.1.2"
  • API_SQL_CONNECTIONSTRING

    • Must be provided. This is access to MessengerApi's instance database that the broker will manage.
    • Example: "Persist Security Info=False;User ID=*****;Password=*****;Initial Catalog=AdventureWorks;Server=192.168.1.2"
  • BROKER_ID

    • Must be provided. This identifies broker's against each other.
    • Example: 15D97720-F5B7-47AA-9C1A-71F98B0B9248
  • MASTER_SERVERS

    • Must be provided, if this instance provides fallback for another instance. Individual server info is separated by semicolon, but data related to the server are separated by comma as BrokerId1,BrokerUrl1,BrokerName1;BrokerId2,BrokerUrl2,BrokerName2, etc.
    • Example: F696442B-E8DC-4074-B34F-94BCECE8E74B,http://localhost:1234,test1;D1B65834-53BA-45F8-A1E1-66C91C7CFCA9,http://localhost:5678,test2
  • SLAVE_SERVERS

    • Must be provided, if this instance wants to share data to another instance for fallback purposes. Same logic applies as for MASTER_SERVERS, except SLAVE_SERVERS do not require BrokerUrl, so the mask is as follows: BrokerId1,BrokerName1;BrokerId2,BrokerName2, etc.
    • Example: 20E4B747-EC58-4071-8AD9-25521F3C4013,test3

PostgreSQL

To run broker's db against postgres, omit the SQL_CONNECTIONSTRING and use this:

  • PERSISTENCE_TYPE: PostgreSql
    • This tells broker to use PostgreSql DB Context.
  • NPG_CONNECTIONSTRING
    • Must be provided.
    • Example: "Host=localhost;Port=5432;Database=myDatabase;Username=postgres;Password=********

If messenger also runs against postgres, the logic is similar:

  • API_PERSISTENCE_TYPE: PostgreSql
  • API_NPG_CONNECTIONSTRING

Additional tunables, with their sustainable default values:

  • HOUSEKEEPING_ENABLED: true
    • Periodically runs housekeeping to remove obsolete messages. Uses HOUSEKEEPING_MESSAGE_AGE_IN_MINUTES to identify what to delete. This housekeeping job only pertains to broker's DB, it doesn't remove any messages from the messenger itself, as messenger has it's own housekeeping job.
  • HOUSEKEEPING_MESSAGE_AGE_IN_MINUTES: 180
    • If a message synchronized by broker is older than set value, it is removed from broker's DB.

Endpoints

Endpoints listed here are consumed by other Brokers.

GET /users

Description
An add-on service for messengerapi that adds inter-broker capability, making messengerapi resilient against outage by giving clients additional messengerapi URLs to query against if main URL becomes inop.
Readme MIT 219 KiB
Languages
C# 100%