Add ListenBrainz architecture docs #1826
Conversation
Co-authored-by: Monkey Do <MonkeyDo@users.noreply.github.com>
docs/developers/architecture.rst
Outdated
| =================== | ||
|
|
||
| Services exclusive to ListenBrainz | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
There was a problem hiding this comment.
"This is a list of the docker containers for ListenBrainz services running in the MetaBrainz server infrastructure"
There was a problem hiding this comment.
is this list in any specific order? we could break it up by webservers, long-running services (ts writer, spot reader), utils (redis, exim), databases (timescale, typesense)
Almost all of these items relate to a specific service in docker-compose.yml, or a python entrypoint. They're also mostly listed in the docker/services directory. I wonder if we could link each item in this list to one of those. Does that make sense?
There was a problem hiding this comment.
I have updated the list to format as a table and made some groupings. If the current ones don't look good, I am fine with changing to a better grouping.
There was a problem hiding this comment.
I have linked the development services to docker-compose.yml. Not sure what we should link prod services to.
docs/developers/architecture.rst
Outdated
| On the other hand, "Permanent" Listens need to be persisted in the database. Timescale Writer service consumes from the | ||
| Incoming queue. It begins with querying the MessyBrainz database for MessyBrainz IDs. MessyBrainz tries to | ||
| find an existing match for the hash of the listen in the database. If one exists, it is returned otherwise it inserts | ||
| the hash and data into the database and returns a new MessyBrainz ID. |
There was a problem hiding this comment.
Suggestion:
Permanent Listens need to be persisted in the database. The Timescale Writer service consumes from the
Incoming queue. It queries the MessyBrainz database to get a temporary MessyBrainz ID for this Listen.
MessyBrainz tries to find an existing match based on a hash of the contents of the listen metadata.
If one exists, it is returned otherwise it inserts the hash and metadata into the database and returns a new MessyBrainz ID.
These services are also described in the "Production Services" section. Do you think it makes sense to talk about components using the name that they have in that list?
There was a problem hiding this comment.
The names are quite similar so it is probably fine this way. Adding listenbrainz and prod repeatedly here seems distracting to me.
Co-authored-by: Alastair Porter <alastair@metabrainz.org>
Initial draft of ListenBrainz architecture docs