Architecture

Kubecord Architecture

This document serves to provide a high-level reference for the architecture of Kubecord.

Websocket Handler

The websocket handler has 3 main tasks. The point is to keep it simple while ensuring Redis cache consistency for the workers.

• Maintain a websocket connection for each shard. Shard count is automatically determined by the /gateway/bot REST endpoint.
• Write state data from events to Redis. This is done before forwarding events to the workers to ensure consistency.
• Send events to NATS using NATS Streaming for consumption by workers.

REST Manager

The REST manager will act as a gateway to the Discord REST API. It will expose each REST endpoint as a function by the means of gRPC. It will also manage rate limiting buckets seamlessly behind the scenes. This way the workers don't need to worry about keeping track of rate limits, and we don't need to synchronize rate limiting data across workers.

Worker Libraries

The worker libraries will be responsible for providing an interface to the rest of the system. A basic workflow will look like this:

• Connect to NATS Streaming and start consuming events.
• Some sort of processing can be done on the event data to build objects to make it easier for developers to interact with the event data.
• Call registered handler functions and pass in the event data.
• Provide an interface to the REST API through a gRPC client library.
• Capture any errors or exceptions that occur in the users code and send to Sentry (if the user has provided a Sentry DSN), otherwise log to the console.

Note: We should expose metrics to prometheus from all components of the system.