Cuando el volumen lo cambia todo

También en 19 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Français (Canada) · Deutsch (Schweiz)

A wheelbarrow buried under a teetering heap of bricks, its tire flattened, in front of a forklift holding a full pallet of the same bricks with ease. — Imagen generada con IA

Módulo 1 de 4 del capítulo Diseñar para la escala, capítulo 7 del curso Data Architect, y el comienzo de la Parte 2. Cada módulo se sostiene por sí solo. Siguiente: Puntos calientes: sesgo de propiedad, de padre y de búsqueda

La pregunta que responde este módulo: ¿qué se rompe a medida que crecen los datos, y cuándo?

Un diseño puede ser perfectamente razonable con 70.000 registros y completamente equivocado con 70 millones. Esa es una de las cosas que hacen difícil la arquitectura de datos. El objeto es el mismo. Los campos son los mismos. Las relaciones son las mismas. Puede que hasta el requisito de negocio sea el mismo. Pero añade unos cuantos ceros y la arquitectura cambia.

Aquí es donde pasamos de Ver a Diseñar. En la Parte 1 aprendimos a ver el negocio, el modelo de datos, el panorama de la empresa, el gobierno y la autoridad. Ahora vamos a poner peso sobre esa arquitectura. Y la primera pregunta que hago es: ¿cuánto va a crecer esto?

Hecho para las transacciones

Salesforce runs some of the largest CRM implementations in the world, and its core database handles “upwards of 1.1 trillion transactions per month.” Salesforce’s own architects describe that database as “optimized for high-performance transactional workloads on structured data” (The Salesforce Platform: Transformed for Tomorrow (se abre en una pestaña nueva)). It’s built for that: transactional work on structured data. And every record comes with a lot of built-in capabilities and functionality that are part of the core Salesforce platform: the object model, sharing and security, pages, reports, automation, search. All of it runs on a multitenant database, where Salesforce writes the SQL, not you. ⟲

Una vez di esta clase en Dreamforce a una sala con muchos administradores de bases de datos de Oracle y SQL Server, y por supuesto preguntaban: “¿Por qué Salesforce no se comporta así? ¿Por qué Salesforce no hace esto?”. Al final sonreían, porque habían entendido el porqué. El capítulo 3 describió Salesforce como una plataforma multiinquilino basada en metadatos: el edificio de apartamentos. No estamos ajustando nuestra propia base de datos dedicada. El almacenamiento, la indexación, el uso compartido, los bloqueos, la optimización de consultas y las protecciones de recursos de Salesforce están diseñados para muchos inquilinos a la vez. Eso no es malo; es la razón por la que obtenemos tanta capacidad sin gestionar infraestructura de bases de datos. Pero significa que el arquitecto necesita entender la forma de la plataforma.

Salesforce lo dice claramente en su propia guía: a medida que los conjuntos de datos crecen, “el tiempo necesario para ciertas operaciones aumenta”, y las decisiones del arquitecto cambian ese tiempo “en varios órdenes de magnitud” (Best Practices for Deployments with Large Data Volumes (se abre en una pestaña nueva)). Eso no es una debilidad. Es el diseño. Con volúmenes pequeños, a veces puedes ignorar la forma de la plataforma. Con volúmenes grandes, te recuerda que está ahí, y lo veremos con mucha claridad con la selectividad y los índices en el próximo capítulo. Por eso el arquitecto tiene que saber hasta qué tamaño llegará esto.

La misma guía termina con la otra mitad de la historia. Salesforce es “un entorno robusto en el que las aplicaciones nativas y personalizadas pueden escalar muy rápidamente a grandes volúmenes de datos y seguir funcionando bien”, y nombra las dos maneras de conseguirlo: hacer que las consultas sean selectivas y reducir la cantidad de datos activos. Millones de registros pueden funcionar bien en Salesforce. Funcionan bien porque alguien diseñó para ellos. De eso trata esta parte del curso.

Mi regla para medir grandes volúmenes de datos

Cuando enseño grandes volúmenes de datos, uso una regla aproximada. No es un límite de Salesforce. Las cifras son valores generales que se comentan en la comunidad, y la propia Salesforce llama a un gran volumen de datos “un término impreciso y elástico”: decenas de miles de usuarios, decenas de millones de registros o cientos de gigabytes de almacenamiento (Best Practices for Deployments with Large Data Volumes (se abre en una pestaña nueva)). Y cuando digo registros, me refiero a registros en un solo objeto, no en todos tus objetos juntos.

Como todas las cifras de este curso, la regla lleva una fecha. Enseguida hablamos de eso.

At about 1 million records in an object, there’s just a little bit of drag as dashboards and reports show up. Not a lot, depending on how you filter. Around 10 million, there’s some effect, but it’s still performing. Heading toward 50 million, you start to notice it: list views taking two, three, four seconds, reports and dashboards taking time. Past 50 million, I like to say you’re driving a convertible with your head out the window, and your hair is blown back. Don’t stick your head out the window: past 50 million you’ve got to be streamlined, and you’ve got to know what you’re doing. And once we’re talking about 100 million records or more, I start asking a different question: should these records be here at all? I’ve heard of people running a hundred million or more in an object. But if you’re at 50 million today, you’re going to 100, 150, 200 million in the years ahead. If you’re not archiving today, when will you? If somebody tells me they have 150 million records in an object and almost nobody ever looks at the old ones, that’s not an operational object any more. That’s an audit log. ⟲

No es casualidad que la regla empiece en un millón. Las propias matemáticas de consulta de la plataforma cambian en “el primer millón de registros”, como muestra el próximo capítulo. Sin embargo, la cifra exacta no es la lección. La lección es: el volumen cambia el diseño.

Clic para ampliar

Cada cero cambia lo que notas. Una regla práctica, no un límite.

La plataforma no deja de crecer

Salesforce publica tres versiones al año. Con el tiempo la plataforma crece, algunos límites se amplían y los sistemas se vuelven más rápidos. Así que no quiero que trates ninguna cifra de este curso como si fuera permanente, incluidas las mías. Salesforce mantiene en línea la edición de sus guías de cada versión, lo que nos permite hacer algo útil: poner diez años uno al lado del otro. Aquí está Winter ‘16, de finales de 2015, junto a Winter ‘27, de 2026.

	Winter ‘16 (2015)	Winter ‘27 (2026)
Objetos grandes (big objects)	Aún no existían	“Rendimiento constante, tengas 1 millón de registros, 100 millones o incluso 1.000 millones”
Columnas de una tabla reducida (skinny table)	100	200
Umbrales de selectividad de los índices	Con tope de 1 millón de registros (estándar) y 333.333 (personalizado)	Sin tope publicado, y el optimizador puede añadir un índice por su cuenta
Almacenamiento de datos mínimo	1 GB por organización, o 20 MB por usuario	10 GB por organización, más almacenamiento por usuario
Lotes de Bulk API al día	5.000	15.000
Niveles de padre a hijo en una consulta SOQL	1	5
Heap de Apex por transacción	6 MB (12 MB asíncrono)	10 MB (25 MB asíncrono)

That’s the upward direction: limits raised, caps removed, new kinds of storage, and an optimizer that now “recognizes that an index can improve performance for frequently run queries” and adds one (Working with Very Large SOQL Queries (se abre en una pestaña nueva)). ⟲

Now look at what didn’t move in those ten years. The definition of a large data volume is word for word the same: “tens of thousands of users, tens of millions of records, or hundreds of gigabytes.” The advice to avoid having any user own more than 10,000 records is the same. And an Apex transaction still gets 100 SOQL queries, 50,000 records and 10 seconds of CPU (Execution Governors and Limits (se abre en una pestaña nueva)). Those are the house rules of the apartment building, the guardrails that keep one tenant from hurting the others, and they’ve barely moved. ⟲

Salesforce también es transparente sobre el ritmo. Publica tres versiones al año, cada una con una nueva versión de la API, y se compromete a “dar soporte a cada versión de la API durante un mínimo de 3 años desde la fecha de su primera publicación”, con al menos un año de aviso antes de que termine el soporte de una versión (SOAP API End-of-Life Policy (se abre en una pestaña nueva)). En la práctica, las versiones viven mucho más: mientras escribo esto, la versión 41.0, de Winter ‘18, sigue teniendo soporte. Si eres nuevo, no necesitas la historia. Pero sí cambia decisiones. La organización que heredas se diseñó con límites más antiguos, y puede que algunas de sus soluciones provisionales ya no hagan falta. La integración que construyes hoy está fijada a una versión de la API que tiene fecha de caducidad. Y el material de estudio escrito hace unas cuantas versiones puede seguir enseñando las cifras de ayer.

Así que cuando leas una cifra en este curso, lee la fecha que la acompaña. Los límites concretos seguirán cambiando, sobre todo hacia arriba, y Salesforce seguirá cambiando de rumbo. La forma de pensar no cambiará: conoce tu Número de Ceros, mantén pequeños los datos activos, haz selectivas tus consultas y consulta la edición actual de la guía antes de comprometerte con una cifra. Por eso enseño la regla como una regla de medir, no como una ley. Por ahora, es un buen punto de partida.

No preguntes cuánto ocupa hoy

Uno de los errores más fáciles es dimensionar una arquitectura a partir de los datos de hoy. Steve Trucking tiene alrededor de 1 millón de entregas al año. Si solo pregunto “¿puede Salesforce manejar un millón de entregas?”, estoy haciendo la pregunta equivocada. Steve Trucking espera un crecimiento anual de alrededor del 30%: 1,0 millones el primer año, 1,3 el segundo, 1,69 el tercero, unos 2,2 el cuarto, unos 2,86 el quinto. Eso es volumen anual. Si conservamos los cinco años, no estamos diseñando para 2,86 millones de entregas; estamos diseñando para unos 9,04 millones. Y eso antes de preguntar cuánta historia existe ya.

Por eso enseño el Número de Ceros de Steve. No te obsesiones al principio con una precisión falsa. Acierta con la magnitud. ¿Diez mil, cien mil, un millón, diez millones, cien millones? La arquitectura puede cambiar cada vez que añadimos un cero.

Ahora multiplica los hijos

La entrega no es el único registro. Steve Trucking tiene una media de 1,6 partidas por entrega, así que en cinco años son unos 14,5 millones de partidas de orden de trabajo. Y hay unos ocho cambios de estado por entrega: unos 72,3 millones de eventos de estado. El requisito sonaba a “hacer seguimiento de las entregas”. La arquitectura tiene que lidiar con decenas de millones de registros relacionados. Un millón de padres con ocho hijos cada uno no es un problema de un millón de registros. Tienes que seguir el modelo.

Y los datos que no pusimos en el núcleo

El checkpoint 1 también nos dio de cuatro a cinco millones de fotos al año, y FleetLink produce unas 200.000 lecturas de GPS al día: aproximadamente 73 millones al año antes del crecimiento. Por eso decidimos no meter cada lectura de GPS, cada foto ni cada cambio de estado en el modelo operativo de Salesforce. Ni siquiera habíamos empezado este capítulo y el Número de Ceros ya nos estaba diciendo algo. Es como decirle al médico: “Me duele cuando levanto el brazo”, y que el médico te diga: “Pues no levantes el brazo”. A veces la mejor manera de resolver un problema de gran volumen de datos es no crearlo en primer lugar.

Las consultas no son lo único que se ralentiza

Cuando la gente oye grandes volúmenes de datos, piensa “las consultas se vuelven lentas”. Sí, y el próximo capítulo trata por completo de consultas y recuperación. Pero es más amplio que eso. A medida que crece el volumen, me importan los cálculos de uso compartido, la propiedad, el bloqueo de registros, las relaciones padre-hijo, las vistas de lista, las listas relacionadas, los informes, los resultados de búsqueda, el procesamiento por lotes, las integraciones, las cargas de datos, los borrados, el archivado, las copias de seguridad y la recuperación. Incluso una decisión de aspecto inofensivo sale cara cuando se repite millones de veces.

Esa es la lección: lo que funciona hoy puede fallar mañana. Quizá nadie lo note con 50.000 registros, ni con 500.000. Luego el crecimiento empuja el objeto por encima de varios millones, y una vieja suposición de diseño se convierte en el cuello de botella. El sistema no se estropeó por azar. La arquitectura cruzó la escala en la que esa decisión importaba.

Los modelos limpios pueden volverse modelos caros

Mi posición de partida sigue siendo: primero diseña limpio y luego retrocede cuando haga falta. Entiende las entidades y las relaciones; no dupliques datos porque sea cómodo. Pero la normalización es un principio, no una regla. Si un informe o una consulta operativa tiene que recorrer constantemente varias relaciones a través de decenas de millones de registros para obtener un valor, a partir de cierta escala puede que copie ese valor más cerca de donde se usa. Eso es desnormalizar.

Supongamos que los informes por socio sobre las partidas de orden de trabajo necesitan constantemente el socio minorista (Retail Partner), que en el modelo limpio está a dos saltos: partida → orden de trabajo → socio. A suficiente escala, puede haber un motivo para poner una copia gobernada del identificador del socio directamente en la partida. Ahora he creado datos duplicados, y eso crea responsabilidad. ¿Cómo se rellena? ¿Puede cambiar? ¿Cómo lo mantengo correcto? ¿Qué copia tiene la autoridad? Son costes reales, y a veces acepto una duplicación controlada para conseguir el rendimiento que necesita el negocio. Diseña hacia la normalización y luego retrocede a propósito cuando la escala te dé un motivo. No desnormalices porque sea más fácil de construir; desnormaliza porque puedes explicar el beneficio y el coste que aceptas.

No conviertas el CRM principal en tu almacén de datos

Hay otro error de escala que veo. El negocio quiere informes, así que seguimos añadiendo datos históricos al CRM operativo, y luego más, hasta que la justificación pasa a ser “lo necesitamos para los informes”. Ahí es cuando pregunto si hemos convertido el sistema operativo en el sistema analítico. Son cargas de trabajo distintas. Steve Trucking necesita Salesforce para gestionar las entregas de hoy: el agente necesita el estado de hoy, el despachador las rutas de hoy, el socio el avance de hoy. Un analista que compara cinco años de rendimiento de entregas por región, socio, camión, clima, equipo y franja de entrega, cruzado con finanzas, es una carga de trabajo analítica. Salesforce puede hacer informes sobre datos operativos. Eso no significa que cada pregunta analítica histórica pertenezca al almacén operativo. Steve Trucking ya tiene Snowflake. Así que pregunta: ¿qué preguntas debe responder el sistema operativo, y cuáles corresponden a la plataforma analítica? La Parte 3 trata el almacén de datos a fondo.

Y las instantáneas de informes no son una estrategia de almacén de datos. Objetos de informes aplanados, registros de instantáneas, copias de valores que facilitan los informes: a veces son legítimos. También pueden ser una manera de posponer la pregunta de arquitectura. Si estoy creando millones de registros adicionales para poder hacer informes sobre los millones que ya tengo, quiero saber dónde termina eso. No sigas fabricando registros operativos porque nadie quiere tener la conversación sobre el almacén de datos.

El volumen tiene forma

Dos sistemas pueden tener 20 millones de registros cada uno y comportarse de forma muy distinta. Uno guarda 20 millones de registros históricos, casi nunca actualizados, que normalmente se obtienen de uno en uno por un identificador conocido, con poca complejidad de uso compartido. El otro guarda 20 millones de registros activos, actualizados constantemente, con una propiedad compleja, muchos informes, muchos usuarios, grandes concentraciones padre-hijo e integraciones frecuentes. No es el mismo problema. Así que el número de registros por sí solo no basta. ¿A qué ritmo crece? ¿Con qué frecuencia cambia? ¿Cómo se consulta, comparte y relaciona? ¿Cuánto tiempo debe seguir activo? ¿Cuánto llega, o cambia, de una sola vez? ¿Qué pasa cuando lo borramos? “Salesforce puede con 20 millones de registros” no es una respuesta. La pregunta interesante es: ¿veinte millones de registros haciendo qué?

La IA va a añadir más ceros

Los agentes pueden crear datos muy rápido: interacciones, tareas, resúmenes, recomendaciones, registros de actividad, resultados intermedios, eventos, información de auditoría. Quizá sea útil. Pero la IA no hace gratis el almacenamiento, ni los cálculos de uso compartido, ni la indexación, y desde luego no hace valiosa una historia inútil. Si un agente crea diez registros donde un proceso humano creaba uno, nuestras suposiciones de volumen pueden ser erróneas antes de que crezca el propio negocio. Todavía no veo que los agentes generen más registros en las organizaciones con las que trabajo, pero es la evolución natural de hacer seguimiento de cada vez más datos.

Más allá del examen: lo que cambia la IA. La IA puede aumentar drásticamente el ritmo al que los sistemas crean y recuperan datos. Modela de forma explícita el volumen generado por agentes en lugar de suponer que los ritmos históricos de transacciones humanas predecirán la escala futura.

Steve Trucking: la arquitectura ya está cambiando

Al final de la Parte 1 tomamos varias decisiones que ahora se refuerzan entre sí. La orden de trabajo es central. El estado actual vive en la organización, y el historial de cada cambio de estado se publica en el almacén de datos, Snowflake. Las fotos viven fuera del núcleo. El GPS en bruto se queda en FleetLink. Con cinco años de crecimiento del 30 %, nos acercamos a 9 millones de órdenes de trabajo, 14,5 millones de partidas y 72,3 millones de eventos de estado, y cientos de millones de lecturas de GPS si las hubiéramos copiado todas.

¿Dejar el GPS en bruto fuera del modelo operativo fue solo una decisión de integración? No; también fue una decisión de escala. ¿Poner las fotos fuera del núcleo fue solo una decisión de almacenamiento? No; otra vez escala. ¿Y el historial de estados? Tiene un valor de negocio real, así que lo conservamos. Pero con 72,3 millones de eventos, mantenerlo fuera de la base de datos operativa marca la diferencia entre una organización que carga con su historia y una organización enterrada por ella. La pregunta que queda para lo que sí mantenemos en el núcleo: ¿cuánto tiempo deben seguir activos esos registros? Ese es el módulo 4.

Clic para ampliar

Sigue el modelo y los ceros se multiplican.

Lo que decide aquí un arquitecto

Cómo es el Número de Ceros hoy, con el crecimiento esperado y a lo largo del periodo de retención, no solo si el volumen de hoy funciona.
Qué estructuras limpias siguen normalizadas, y dónde la escala justifica una desnormalización controlada.
Qué datos se quedan en el núcleo operativo de Salesforce y cuáles corresponden a almacenamiento especializado, plataformas analíticas u otros sistemas.
Si un requisito de informes es realmente operativo, o una señal de que el negocio necesita una arquitectura analítica.
Cómo los nuevos productores, como los agentes, cambian las suposiciones de volumen antes de que sus registros se conviertan en el problema de mañana.

La arquitectura de grandes volúmenes de datos no consiste en tener miedo a las cifras grandes. Salesforce ejecuta implementaciones muy grandes. Un millón de registros no es automáticamente un problema; tampoco diez millones ni cien millones. Pero cada cero debería hacerme hacer otra pregunta: ¿cómo los encontraremos, quién es su propietario, cómo se comparten, con qué están relacionados, con qué frecuencia cambian, cuánto tiempo los necesitamos y dónde deberían vivir? En la Parte 1 aprendimos a reconocer las entidades y relaciones correctas. Ahora nos aseguramos de que esos huesos puedan soportar el peso, porque lo que funciona hoy puede fallar mañana.

Explora

Salesforce Help, Data and File Storage Allocations (se abre en una pestaña nueva): 10 GB of data storage since late March 2019, checked 2026-11-01. ⟲
Salesforce, Best Practices for Deployments with Large Data Volumes, edición Winter ‘27 (se abre en una pestaña nueva) (versión 264, copia archivada (se abre en una pestaña nueva)), consultado el 2026-10-20.
Salesforce Developers, Best Practices for Deployments with Large Data Volumes (se abre en una pestaña nueva), Winter ‘27, checked 2026-11-01. ⟲
Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (se abre en una pestaña nueva), checked 2026-11-01. ⟲
Salesforce, Best Practices for Deployments with Large Data Volumes, edición Winter ‘16 (se abre en una pestaña nueva) (copia archivada (se abre en una pestaña nueva)) (versión 198), consultado el 2026-10-20.
Salesforce, Developer Limits and Allocations Quick Reference, edición Winter ‘16 (se abre en una pestaña nueva) (copia archivada (se abre en una pestaña nueva)) y edición Winter ‘27 (se abre en una pestaña nueva) (copia archivada (se abre en una pestaña nueva)), consultado el 2026-10-20.
Salesforce Developers, SOAP API End-of-Life Policy (se abre en una pestaña nueva), checked 2026-11-01. ⟲
Salesforce Developers, Execution Governors and Limits (se abre en una pestaña nueva), Apex Developer Guide, Winter ‘27, checked 2026-11-01. ⟲
Salesforce Developers, Working with Very Large SOQL Queries (se abre en una pestaña nueva), Apex Developer Guide, Winter ‘27, checked 2026-11-01. ⟲
SteveTechArc, Documentos de Salesforce por versión: las guías citadas aquí, una por año desde Winter ‘16 hasta hoy, cada una con una copia archivada.
El planteamiento de Steve Trucking, sección 4 (volúmenes).