Todo documento MongoDB debe tener un campo único dentro de su colección. Si la aplicación no lo envía, el driver o el servidor puede generar uno. El tipo más habitual es , pero MongoDB permite utilizar strings, UUIDs, números u otros valores BSON válidos.
Una colección puede contener millones de documentos con campos repetidos. MongoDB necesita una identidad estable para distinguir cada uno, referenciarlo y actualizarlo de forma precisa.
Sin identificador único, operaciones como estas serían ambiguas:
identidad del documento
↓
_id único en la colección
↓
índice automático
↓
lecturas, updates y references precisos
El ID responde “¿qué documento es?”. No debería asumir responsabilidades que pertenecen a otros campos, como fecha de creación, slug público, número de factura o shard key.
Si no se proporciona _id, el driver normalmente añade uno antes de enviar el documento. Desde la perspectiva de la aplicación, conviene saber qué capa lo genera para mantener tipos y pruebas consistentes.
No asumas que el servidor siempre es quien crea el valor.
Ordenar por _id puede aproximar el orden de generación cuando todos son ObjectId y se crean de forma normal. No garantiza un orden total exacto entre procesos durante el mismo segundo.
Para paginación o auditoría, suele ser más claro utilizar:
JavaScript
{createdAt:-1,_id:-1}
createdAt expresa el concepto del dominio y _id funciona como tie-breaker único.
Un ObjectId no debe utilizarse como mecanismo de autorización. Aunque no sea un entero secuencial simple, puede exponerse, copiarse o inferirse parcialmente.
Este endpoint sería inseguro si solo depende del ID:
Texto
GET /orders/:id
La consulta debe incluir el scope autorizado:
TypeScript
const order =await orders.findOne({
_id: orderId,
businessId: authenticatedBusinessId
});
La autorización verifica pertenencia y permisos. Un ID difícil de adivinar solo reduce enumeración casual; no protege el recurso.
El índice _id no convierte automáticamente _id en una buena shard key.
Una shard key debe analizar:
cardinalidad;
distribución de escrituras;
query isolation;
monotonicidad;
tenant locality;
crecimiento;
posibilidad de targeted queries.
Un ObjectId contiene un componente temporal y puede ser aproximadamente creciente. Elegir _id sin analizar workload puede concentrar inserciones en ciertos rangos dependiendo de la estrategia.
Además, en una colección sharded la unicidad global de ciertos índices depende de incluir la shard key y de las reglas actuales de MongoDB.
Un “último número + 1” leído y escrito sin atomicidad produce duplicados. Los números de negocio requieren contador atómico, rangos o servicio dedicado según volumen.
_id identifica un documento y tiene un índice unique automático. ObjectId es un valor eficiente y distribuido, pero no es una fecha de negocio, autorización ni shard key universal. Separa identidad interna, identificadores públicos y números del dominio cuando sus responsabilidades sean diferentes.
Comprueba lo aprendido
¿Por qué ObjectId no reemplaza createdAt?
¿Qué diferencia existe entre _id, publicId y orderNumber?
¿Cómo protegerías unicidad de SKU por negocio?
¿Por qué validar formato no equivale a autorizar acceso?
¿Qué costes introduce utilizar strings largos como _id?
¿Por qué cambiar _id requiere una migración especial?