Coda

Contexto y problema

Arquitectura

Tres decisiones técnicas

1. a.Un pipeline de catálogo que respeta a sus fuentes

   Decisión

   Spotify siembra el catálogo y MusicBrainz lo enriquece; un match se acepta solo con score >= 80. Las importaciones son idempotentes y reanudables: ids de job determinísticos, checkpoint de paginación en Redis y upserts sobre spotifyId único.

   Por qué

   MusicBrainz permite 1 request por segundo, y el límite se aplica dos veces: un limiter de BullMQ para toda la flota (1 job cada 1100 ms) y un gate serializado en el cliente. Los fallos se reintentan hasta 5 veces con backoff exponencial.

   Tradeoff

   Importar es lento a propósito. A cambio, se respeta el límite de MusicBrainz y un proceso caído retoma donde quedó sin duplicar datos.

2. b.Búsqueda como proyección reconstruible

   Decisión

   Postgres es la fuente de verdad. Meilisearch es una proyección de lectura que se actualiza a través de la cola search-sync, y reindex:search la reconstruye desde cero.

   Por qué

   La búsqueda tolerante a typos necesita un motor dedicado, pero ese motor no debería ser dueño de ningún dato. Si el índice se corrompe o cambia el esquema, se vuelve a generar.

   Tradeoff

   Consistencia eventual: entre una escritura y su sincronización, la búsqueda puede mostrar datos levemente desactualizados.

3. c.Recomendaciones v1: simples y explicables

   Decisión

   Una heurística precalculada en workers: 0.5 género + 0.35 artista + 0.15 popularidad (log). Un prefiltro SQL por los 5 géneros principales del usuario acota a 300 candidatos y se guardan los 50 mejores. Se regeneran con un debounce de 5 minutos y un refresh nocturno.

   Por qué

   Cada recomendación guarda su razón (topGenre, matchedArtist), así la interfaz puede mostrar “Because you like {género}” o “Because you follow this artist” en lugar de una caja negra.

   Tradeoff

   Deliberadamente simple antes de cualquier modelo de ML. Captura menos matices, pero es barata, predecible y fácil de depurar.

Problemas difíciles

• El techo de la búsqueda de Spotify

  La búsqueda de Spotify corta la paginación en el offset 1000. Eso bloquea la meta de un catálogo de 100k álbumes si solo se siembra por búsqueda.

• Un job que BullMQ ignoraba en silencio

  Con ids determinísticos, un job que quedaba en estado completado hacía que BullMQ salteara el siguiente con el mismo id, sin error. Se resolvió con removeOnComplete.

• Ids de job con dos puntos

  BullMQ rechaza : en los ids de job, así que los ids determinísticos tienen que armarse con otro separador.

• Specs que nunca corrían en CI

  Un error de orden en el pipeline de CI hacía que los specs contra infraestructura real se saltearan siempre. Un CI en verde no prueba nada si los tests importantes no se ejecutan.

Cómo se testea

Hecho y roadmap