¿Qué es el problema de consultas N+1?

El problema de consultas N+1 es un patrón donde leer N registros dispara una consulta extra por registro — N+1 idas a la base en lugar de una o dos. Es el bug de performance serio más común en aplicaciones respaldadas por datos, y el mejor camuflado: cada query individual es rápida, el código se lee perfecto y la página funciona — justo hasta que llegan los tamaños de datos reales.

Puntos clave

El bug, a plena vista

// 1 query: trae 100 posts
const posts = await postRepo.findRecent(100);

for (const post of posts) {
  // +1 query POR POST — post.author parece una propiedad,
  // pero corre lazy loading: SELECT * FROM users WHERE id = ?
  render(post.title, (await post.author).name);
}
// Log de queries: 1 + 100 = 101 idas a la base para un solo render de página

El arreglo, como lo expresan los SDKs — declara la relación por adelantado y la plataforma la trae en la misma solicitud:

// JavaScript / Node.js — Back4app JS SDK
// The fix: fetch the relation in the same request — 1 query, not N+1
const query = new Parse.Query('Comment');
query.equalTo('post', post);
query.include('author');                    // eager-load the pointer
const comments = await query.find();        // one round trip, total

comments.forEach((c) =>
  render(c.get('text'), c.get('author').get('username')) // already loaded
);

// Flutter / Dart — Back4app Flutter SDK
// The fix: fetch the relation in the same request — 1 query, not N+1
final query = QueryBuilder<ParseObject>(ParseObject('Comment'))
  ..whereEqualTo('post', post.toPointer())
  ..includeObject(['author']);              // eager-load the pointer
final response = await query.query();       // one round trip, total

// iOS / Swift — Back4app Swift SDK
// The fix: fetch the relation in the same request — 1 query, not N+1
let query = Comment.query("post" == post)
  .include("author")                        // eager-load the pointer
query.find { result in
  if case .success(let comments) = result { // one round trip, total
    comments.forEach { render($0.text, $0.author?.username) }
  }
}

// Android / Kotlin — Back4app Android SDK
// The fix: fetch the relation in the same request — 1 query, not N+1
val query = ParseQuery.getQuery<ParseObject>("Comment")
query.whereEqualTo("post", post)
query.include("author")                     // eager-load the pointer
query.findInBackground { comments, e ->     // one round trip, total
  if (e == null) comments.forEach {
    render(it.getString("text"), it.getParseObject("author")?.getString("username"))
  }
}

El costo, multiplicado

La aritmética que los explicadores se saltan — tiempo total ≈ query de lista + (N × latencia de round trip):

Los arreglos publicados coinciden con la matemática: páginas cayendo de 1,4 s a 0,16 s, endpoints acelerándose 30× y más. Dos corolarios que vale la pena fijar: la paginación acota N — un tamaño de página limitado acota el radio de daño incluso antes del arreglo real; y la versión de red es peor — cuando cada una de las N llamadas es una solicitud HTTP y no una query local, multiplica por decenas de milisegundos en vez de un solo dígito.

Las cuatro salidas

La última fila es el caso famoso de GraphQL: los resolvers se disparan por objeto padre, recreando el loop del lado del servidor, y el patrón loader — juntar las claves en un tick, traer una vez, memoizar por solicitud — es la cura estándar de la industria. Una regla sutil viaja con él: los loaders tienen scope de solicitud; uno global se convierte en una caché vieja con bugs de autorización.

Detección: caza las queries rápidas

La firma del N+1 está invertida respecto del trabajo normal de performance: buscas muchas queries idénticas y rápidas, no una lenta — y por eso los logs de queries lentas, la herramienta habitual, nunca lo ven. Los métodos que sí: el logging de debug del ORM (la misma sentencia, N parámetros distintos, un solo render); las vistas de spans del APM, donde la cascada de spans cortos idénticos es inconfundible; y el más barato de todos — cuenta las queries de una carga de página en desarrollo, con un umbral en la cabeza: una página de lista debería costar queries de un solo dígito, no múltiplos de sus filas. El gemelo del lado de escritura también merece su auditoría: un loop de insert-por-ítem es N+1 de escrituras, arreglado con operaciones bulk.

Casos de uso comunes

• Vistas de lista con autores, dueños o estados — el hogar canónico: cada feed, bandeja de entrada y tabla que une personas con ítems.
• APIs GraphQL — los campos de lista anidados son estructuralmente N+1 hasta que existen loaders.
• Bases de documentos — un find por documento referenciado; se arregla con include, IN en batch o embebiendo, según las reglas de modelado.
• Fan-outs de microservicios — una lista del servicio A, una llamada HTTP al servicio B por ítem; los endpoints compuestos y los BFFs existen para terminar con esto.
• Jobs en segundo plano — el loop que procesa 10.000 registros con dos queries cada uno, costando horas en silencio.

Lazy loading vs. eager loading: matriz de decisión

Y la regla de auditoría permanente que sobrevive a cualquier matriz: toda relación tocada dentro de un loop es culpable hasta que el log de queries demuestre lo contrario.

Limitaciones y trade-offs

• El eager loading puede sobrecorregir. Incluir relaciones pesadas en todas partes cambia N+1 por payloads inflados y joins anchos — incluye lo que la pantalla renderiza, no el grafo completo.
• Los joins tienen su propio precipicio. Los joins uno-a-muchos duplican las filas del padre por cada hijo; con fan-out alto, la lectura en batch de dos queries le gana al join único.
• Los loaders agregan maquinaria. El scope por solicitud, la invalidación de caché dentro de la solicitud y las ventanas de batching son código real — el precio del batching automático.
• Los frameworks lo reintroducen en silencio. Los serializers, los helpers de plantillas y los reviews de “solo un campo más” son la forma en que las páginas arregladas recaen; el chequeo de conteo de queries pertenece al CI, no a la memoria.
• El arreglo es por ruta, no global. N+1 es un bug de patrón de acceso; cada pantalla nueva vuelve a hacer la pregunta.

El N+1 en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Sus SDKs hacen del arreglo el idioma y no la remediación: las relaciones son Pointers tipados, e include() — las pestañas de código de arriba — las trae en la misma solicitud, en batch del lado del servidor. La API GraphQL resuelve queries anidadas sin fan-out por campo, y los defaults de paginación acotan N antes de que saque los dientes. El loop que causa el N+1 no tiene una forma natural de escribirse — que es la mejor clase de arreglo: el que nadie tiene que recordar.