Recorrido por una tabla de clasificación: eventos de puntuación, un conjunto ordenado derivado y clasificaciones reconstruibles

Objetivo

Clasificar a los miembros por puntuación con consultas rápidas de top-N y de «mi posición», tablas por período y clasificaciones que puedan reconstruirse a partir de un historial de eventos cuando se pierda el almacén de clasificación.

Requisitos previos

Una definición de la puntuación por tabla (mejor resultado único, suma acumulada o valor más reciente), una regla de desempate, períodos de tabla (histórico, semanal, diario) y una vía del lado del servidor que genere las puntuaciones; los clientes nunca envían puntuaciones directamente.

Pasos

1. Restricciones: el envío de puntuaciones tiene autoridad del servidor; las consultas de posición predominan; una tabla de período se cierra en un momento fijo; el almacén de clasificación es una caché y los eventos son la fuente de verdad.
2. Componentes: un escritor de eventos de puntuación; un actualizador que aplica los eventos a una estructura ordenada por tabla; una API de consulta (top N, posición y puntuación de un miembro, vecinos alrededor de una posición); un rotador de período que abre y cierra tablas; una tarea de reconstrucción.
3. Modelo de datos: score_event(id, board, member, value, occurred_at, source, idempotency_key unique); board(id, period_start, period_end, aggregation, tie_rule, closed_at); derivado: un conjunto ordenado por tabla, indexado por miembro, con la puntuación agregada. La documentación de Redis describe los conjuntos ordenados con búsquedas de posición en O(log(N)) respecto al número de elementos y menciona las tablas de clasificación como un uso habitual.
4. Empates: un conjunto ordenado ordena las puntuaciones iguales por la cadena del miembro, lo cual es arbitrario para los usuarios; conviene codificar la regla de desempate en la propia puntuación (por ejemplo, score * K - seconds_since_period_start para «gana quien llegó antes», con K por encima de la duración del período en segundos y el resultado dentro del rango entero exacto de un double) o resolver los empates en la capa de consulta solo para la página visible.
5. Agregación: «mejor resultado» conserva el máximo, «suma» incrementa, «más reciente» sobrescribe; fijar una sola opción por tabla, porque una reconstrucción debe reproducir los mismos valores a partir de los eventos.
6. Modos de fallo: eventos duplicados tras un reintento (la clave de idempotencia única los rechaza antes del actualizador); pérdida del almacén de clasificación (reconstrucción a partir de los eventos, empezando por el período actual, ya que las tablas son independientes entre sí); un límite de período cruzado mientras hay eventos en tránsito (enrutar por occurred_at, no por el momento de llegada); una tabla global con millones de miembros (el top N y la posición de un único miembro siguen siendo baratos; las bandas de percentiles se aproximan después); trampas (validar las puntuaciones contra las reglas en el servidor, conservar source para auditoría).
7. Medir: el retraso entre el evento y su visibilidad, la latencia de las consultas de posición, el tiempo de reconstrucción por tabla, los eventos duplicados rechazados, las disputas por período.
8. No en primera instancia: tablas de amigos y regionales, instantáneas históricas, envío en tiempo real de cambios de posición, lógica de recompensas.

Resultado esperado

Las consultas de top-N y de posición de un único miembro se responden desde la estructura ordenada, una tabla perdida se reconstruye a partir de los eventos con resultados idénticos, y un período se cierra de forma determinista.

Límites y base de verificación

Diseño propuesto, sin mediciones. Una estructura ordenada en memoria crece con el número de miembros por tabla; el diseño asume tablas acotadas por período o particionadas (sharded) por región.