Lanzado en
producción.

LO QUE CONSTRUÍ

• ▸El esquema del índice y su configuración semántica. La regla que apliqué: buscable solo donde el texto realmente se busca, filtrable donde algo acota una consulta, facetable solo donde la UI ofrece un desglose. Cada capacidad cuesta tamaño de índice, así que no las activás todas.
• ▸El pipeline que trae los comentarios del almacén analítico, enriquece cada uno con el contexto de su club y su pregunta, los deduplica y los empuja al índice.
• ▸Cargas por lotes para el backfill histórico: alrededor de mil documentos por lote, tres lotes corriendo en paralelo. Suficiente para mover mucha data, sin que los errores se vuelvan difíciles de razonar.
• ▸Reintentos con backoff exponencial, y rollback cuando sigue fallando: los documentos parciales se borran del índice y la marca de indexado del comentario queda sin valor, así una ejecución posterior lo vuelve a tomar. Una respuesta nunca queda indexada a medias.
• ▸Una función programada que mantiene buscables los comentarios nuevos, más la capa de suscripción y cuota de prueba y las APIs detrás de ella.

LO QUE CONSTRUÍ

• ▸Tres extractores, uno por sistema de reservas. Antes de escribir una línea de mapeo, pegué contra el endpoint de cada proveedor y leí el payload crudo. Ni siquiera coincidían en el nombre del campo para rondas de nueve o de dieciocho hoyos.
• ▸Una única tabla de staging a la que todos normalizan: club, proveedor, cantidad de hoyos, fecha de juego y una marca de procesado. Los proveedores difieren en el borde; pasada esa tabla, nada río abajo sabe ni le importa de qué sistema vino una ronda.
• ▸Cada club procesado dentro de su propio try/catch, con cualquier error registrado como dato y reintentado en la siguiente corrida. En un job batch multi-tenant, una excepción es un dato, no una señal de frenar. La credencial vencida de un club no debería terminar el día de los otros doscientos.
• ▸La transformación: agrupar las rondas en staging por club y por mes, separar las de nueve y dieciocho hoyos en métricas distintas, crear el registro contenedor anual si cambió el año, y después crear el hecho o sumar al valor que ya está.
• ▸Un log estructurado que registra cada resultado, incluido «no había nada que procesar». Corriendo desatendido, no hacer nada en silencio tenía que ser un estado que alguien pudiera ver.

LO QUE CONSTRUÍ

• ▸Primero hice que los clubes fueran buscables geográficamente. El registro de cuenta tenía una dirección pero no coordenadas, así que agregué una ubicación GeoJSON y usé la consulta geoespacial de MongoDB para encontrar clubes dentro de un radio, de modo que la base de datos hace el trabajo de distancias en vez de traer todo y filtrar en código.
• ▸El modelo de dominio: el modo de selección como un enum explícito (radio o lista elegida a mano), más filtros por tipo de instalación y límites mínimo/máximo tanto para la lista generada como para lo que un encuestado puede responder.
• ▸Un servicio de sincronización que mantiene correcta la lista de comparación de cada club a través de cuatro disparadores distintos, agregando clubes cuando entran en rango y marcando como eliminados los que salen.
• ▸La API de configuración y el editor de la pregunta en la plataforma interna de administración.
• ▸La transformación de la respuesta: cada respuesta aterriza como filas de hechos, y el dashboard agrupa por club y suma al momento de la consulta. Nada guarda un total por club; el gráfico de distribución se calcula cuando alguien abre el reporte.

LO QUE CONSTRUÍ

• ▸La tabla de riesgo de abandono por miembro con categorías de riesgo y flujos para contactarlos, tarjetas de KPI, y las vistas de ingresos en riesgo y distribución del riesgo.
• ▸Cada número al que se refiere un insight: variaciones de tasa de abandono, comparaciones, lo que la historia necesite. Eso llega desde el backend ya calculado. Mi parte es el frontend: mostrarlo, y escribir el prompt base que le entrega esos números terminados al modelo, así el modelo nunca hace aritmética, solo redacta.
• ▸El ID de cuenta tomado de una cookie httpOnly y revalidado del lado del servidor en cada request, nunca leído del cuerpo del request.
• ▸La tarjeta de insight transmitida por separado, para que esperar al modelo no bloquee el renderizado de los KPIs y las tablas.
• ▸Mi primer trabajo en producción con Next.js: App Router, React 19, TypeScript y TanStack Query/Table sobre el backend .NET existente.

LO QUE CONSTRUÍ

• ▸Propagación de los cambios de una encuesta desde una cuenta padre hacia sus hijas.
• ▸Un diff a tres bandas (el padre antes, el padre después y el estado actual de la hija), con la misma forma que un merge de git. Comparar solo las dos versiones actuales no puede distinguir «nunca divergió» de «personalizado a propósito»; traer el ancestro común sí puede.
• ▸Las hijas que divergieron quedan excluidas del push por defecto y se le muestran a un administrador, con la sobrescritura forzada como una acción aparte y deliberada.