chore(lazer) How Lazer works #879
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
|
||
| - **Authentication**: Validates publisher access tokens and optional Ed25519 signatures. | ||
| - **Rate limiting**: Enforces configurable limits of price updates per publisher. | ||
| - **Message forwarding**: Publishes validated updates to NATS or Kafka. |
There was a problem hiding this comment.
We shouldn't mention Kafka because we're not currently using it. I'd also add some description for the role of NATS, like this:
| - **Message forwarding**: Publishes validated updates to NATS or Kafka. | |
| - **Message forwarding**: Publishes validated updates to an internal message queue (a NATS cluster). |
| - **History Service**: Maintains a connection to the History Service to cache historical data for circuit breaker validation. | ||
|
|
||
| The Relayer also maintains a connection to the History Service to cache historical data for circuit breaker validation. |
There was a problem hiding this comment.
This is not correct. Relayer doesn't connect to history service.
| ### Aggregator Component | ||
|
|
||
| The Aggregator is a library component embedded within both the Router and History Service. | ||
| It consumes publisher updates from the message bus and computes aggregated price feeds. |
There was a problem hiding this comment.
We try to call them just "feeds", not "price feeds", because there are also feeds for funding rates, and more kinds of feeds may be added later.
| The system supports dual message queue backends for flexibility. This allows the system to be deployed in a multi-datacenter environment. | ||
|
|
||
| - **NATS Jetstream**: Provides pub/sub messaging with stream persistence. | ||
| - **Apache Kafka**: Can be used instead of NATS for message transport. |
There was a problem hiding this comment.
We don't need to talk about Kafka because we don't use it (yet?).
|
|
||
| The architecture consists of four main services that work together to provide ultra-low-latency data to consumers. | ||
|
|
||
| ### INSERT DIAGRAM HERE |
There was a problem hiding this comment.
I think you want the "components" below to actually be "services" for clarity. This will also allow you to line up the elements in the diagram with the text blocks below. Given that, the subsections below should be: publishers, relayers, message queue, routers, history service
Aggregation logic can be rolled into routers, and you can drop the message transport layer part.
Also, please include who operates the components and the stuff around no reordering etc etc that we discussed
3 participants
Description
Type of Change
Areas Affected
Checklist
pre-commit run --all-filesto check for linting errorsRelated Issues
Closes #
Additional Notes
Contributor Information
Screenshots