Lo que funciona hoy puede fallar mañana

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)

Capítulo 7 de Data Architect, y el comienzo de la Parte 2: Arquitectura a escala. Anterior: Datos maestros e identidad.

Un diseño puede ser perfectamente razonable con 70.000 registros y completamente equivocado con 70 millones. El objeto es el mismo, los campos son los mismos, las relaciones son las mismas. Añade unos cuantos ceros y la arquitectura cambia.

Start with what the platform is built for. Salesforce’s core database handles “upwards of 1.1 trillion transactions per month,” and Salesforce’s own architects describe it 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 transactions, on a multitenant database where Salesforce writes the SQL, not you. At small volumes you can ignore the platform’s shape. At large volumes, it reminds you it’s there. ⟲

So I teach large data volumes with a rough ruler, for records in a single object. At about 1 million, there’s a little drag as dashboards and reports show up. Around 10 million, some effect, but still performing. Heading toward 50 million, you notice it: list views take two, three, four seconds. Past 50 million, you’re driving a convertible with your head out the window, and your hair is blown back: you’ve got to be streamlined, and you’ve got to know what you’re doing. At 100 million or more, I start asking a different question: should these records be here at all? That’s a rule of thumb from the community, not a Salesforce limit. The lesson is that volume changes the design, and most large-data-volume problems are design problems: cheap to prevent, expensive to fix. ⟲

Clic para ampliar

La Parte 1 nos enseñó a ver. La Parte 2 pone peso sobre la arquitectura. Este capítulo es la primera prueba: ¿puede el esqueleto cargar con los ceros?

A small four-seat propeller plane parked beside a wide-body passenger jet that towers over it: the same job, built for a hundred times the load.

Image generated with AI. ⟲

Las ideas de este capítulo

Planifica con el Número de Ceros, con el crecimiento y a lo largo del periodo de retención, no con la cifra de hoy. Un millón de padres con ocho hijos cada uno no es un problema de un millón de registros.
Lo que funciona hoy puede fallar mañana. El volumen ralentiza el uso compartido, los bloqueos, las vistas de lista, los informes, las cargas y los borrados, no solo las consultas.
Diseña limpio y luego retrocede a propósito cuando la escala te dé un motivo, y no conviertas el CRM principal en tu almacén de datos.
10,000 children per parent is a design threshold, not a limit: Salesforce draws the same line, and past about 20,000 I’ve seen visible lag. Account pools work, but hide the placeholder parents. ⟲
Los propietarios de gran volumen se quedan fuera de la jerarquía de funciones, o en su propia función estable en la cima, y fuera de los grupos de las reglas de uso compartido.
Quién es propietario de los registros creados por máquinas depende de si la propiedad importa para el uso compartido.
A escala, una realineación de seguridad es una operación de datos: aplaza los cálculos de uso compartido, ensaya en un sandbox completo y recalcula una sola vez. Y nunca hagas públicos los datos porque lo privado es más lento.
Si no archivas hoy, ¿algún día vas a archivar? Decide la eliminación el primer día, haz una copia de seguridad antes de borrar y mantén los archivos localizables.
Si los datos archivados siguen al alcance de los agentes es una decisión del negocio.

Dónde causa problemas el volumen

Lo que crece	Lo que ralentiza	Dónde se trata
Registros en un objeto	Consultas, vistas de lista, informes	Módulo 1; capítulo 8
Hijos bajo un padre, registros bajo un propietario	Bloqueos, recálculo del uso compartido	Módulo 2
Hijos bajo un solo padre principal-detalle	Bloqueos, resúmenes acumulados, borrado en cascada, una decisión difícil de deshacer	Módulo 2
Usuarios, funciones, grupos y reglas	Recálculo del acceso, realineaciones	Módulo 3
Historial que nadie usa	Todo, además de almacenamiento y riesgo	Módulo 4

El recorrido de este capítulo

Cuatro módulos, cada uno se sostiene por sí solo.

When Volume Changes Everything. Built for transactions, the ruler, the Number of Zeros at 30% growth, denormalizing for scale, and keeping analytics out of core. ⟲
Puntos calientes: sesgo de propiedad, de padre y de búsqueda. Demasiados registros apuntando a una sola cosa, grupos de cuentas, principal-detalle con volumen (cuenta los hijos antes de elegir la relación), propietarios de gran volumen y quién es propietario de los registros creados por agentes.
El volumen se encuentra con el modelo de uso compartido. La propiedad como palanca de acceso, jerarquías estables, cálculos de uso compartido aplazados, bloqueo granular y aislamiento de socios a escala.
Si no archivas hoy…. El ciclo de vida desde el primer día, copia de seguridad antes de borrar, dónde vive el archivo, el archivado en tres pasos, y los agentes y los datos antiguos.

Lo que decide aquí un arquitecto

Cuánto crece cada objeto, con el crecimiento y a lo largo de su periodo de retención.
Dónde se concentran los registros, y qué concentraciones son peligrosas.
Qué significa la propiedad para cada objeto de gran volumen, incluidos los que crean los agentes.
Cómo escala el modelo de acceso, y cómo se planifican las grandes realineaciones.
Cómo salen los datos: archivado, purga, copia de seguridad, y quién puede seguir encontrándolos.

Más allá del examen: los agentes añaden ceros. Pueden crear diez registros donde una persona creaba uno, ser propietarios de todos ellos por defecto, recuperar datos más rápido que nadie y llegar a los archivos a menos que alguien decida que no deben hacerlo. Cada módulo termina con lo que cambia la IA en su parte del problema.

Explora

Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (se abre en una pestaña nueva), checked 2026-11-01. ⟲
Salesforce Developers, Designing Record Access for Enterprise Scale (se abre en una pestaña nueva) (Winter ‘27), checked 2026-11-01. ⟲
Salesforce Developers, Best Practices for Deployments with Large Data Volumes (se abre en una pestaña nueva) (Winter ‘27), checked 2026-11-01. ⟲

Siguiente: Arquitectura de consultas y recuperación