Gamificar una comunidad sin romper el rendimiento

Back2OldGames es un archivo descargable enorme con comunidad encima: perfiles, puntos, subidas de los propios usuarios. Y lo administra una sola persona. Ese último dato condiciona todas las decisiones técnicas del proyecto.

back2oldgames.com En vivo

Gamificar es fácil. Gamificar sin escribir en cada visita, no

Un sistema de puntos parece inocente hasta que se mira lo que hace en la base de datos. Cada visita a una ficha suma una vista; cada descarga, un punto; cada comentario, otro. Si cada uno de esos eventos es una escritura inmediata, cualquier caché deja de servir: la página tiene que ejecutarse para poder contar.

La forma de tenerlo todo es separar leer de contar. La página se sirve cacheada y el recuento viaja aparte, en una petición pequeña que no bloquea el pintado. Los eventos se acumulan y se consolidan por lotes en vez de escribir fila a fila. El marcador de un usuario no tiene que ser exacto al segundo; tiene que ser exacto cuando lo mira.

Los rankings son la trampa clásica

Una tabla de clasificación es una consulta con ORDER BY sobre una suma de eventos. Calculada en vivo, es la consulta más cara del sitio y se pide desde la portada, que es la página más visitada. Es la combinación perfecta para caerse un sábado por la tarde.

Se precalcula. El ranking se genera cada cierto tiempo y se guarda ya ordenado; la portada solo lo lee. Que un ranking tenga unos minutos de retraso no lo nota nadie salvo el que acaba de subir un puesto, y ese lo ve al recargar.

Las descargas no las sirve PHP

El archivo es la razón de existir del sitio, y también la parte que más ancho de banda consume. Servir un fichero grande desde PHP significa un proceso de PHP ocupado durante toda la descarga: veinte descargas simultáneas y no queda nadie para atender páginas.

La descarga la sirve el servidor web, no la aplicación. La aplicación comprueba permisos, registra el evento y delega la entrega. Delante va Cloudflare, que además absorbe el pico cuando un enlace se comparte en un foro y llegan mil personas a la vez.

Contenido de usuario: moderar es un problema de diseño

Cuando la comunidad sube contenido, la administración crece sola. Con una sola persona al mando, la moderación tiene que estar diseñada para que el caso normal no requiera intervención:

• Validación estricta en la subida —tipo real del fichero, no la extensión— para que lo que no debería entrar no entre y no haya que sacarlo después.
• Cola de revisión con lo dudoso arriba, no una bandeja cronológica: lo que lleva más tiempo esperando no es lo que más urge mirar.
• Acciones en bloque. Aprobar cuarenta subidas legítimas de golpe es la diferencia entre diez minutos y una tarde.
• Reputación acumulada: quien lleva doscientas subidas buenas no pasa por la misma cola que quien llega hoy.

Esto no es una función más de la web. Es lo que decide si el proyecto sigue vivo dentro de dos años o si el administrador se quema.

El fichero subido es la puerta de entrada favorita de un atacante

Cualquier sitio que acepte subidas hereda el mismo riesgo: que alguien suba algo ejecutable y consiga que el servidor lo ejecute. Las defensas se apilan y ninguna basta sola: los ficheros se guardan fuera del directorio público, se renombran, se sirven desde una ruta que no interpreta código, y el directorio de subidas tiene la ejecución desactivada a nivel de servidor.

Es el mismo criterio con el que montamos el mantenimiento de cualquier sitio que administramos: no confiar en una sola capa, porque la que falla siempre es la que dabas por segura.

Un archivo vivo pesa cada año más

Un proyecto de comunidad no se entrega y se olvida: crece. La medida del éxito de la arquitectura no es cómo va el día del lanzamiento, es si dentro de tres años y con el triple de contenido sigue siendo administrable por la misma persona.

Cada decisión de este proyecto se tomó contestando a la misma pregunta: ¿esto lo va a poder mantener una persona sola dentro de tres años?

Ignacio Pineda, Intervolutions