Uma consideração importante ao projetar um esquema para o MongoDB não é quais são seus dados, mas como você os usará. Sem descobrir que tipo de leituras e gravações você fará (e qual será o desempenho delas), pode ser difícil projetar um esquema "ideal".

Existem algumas diretrizes básicas que você pode considerar para evitar problemas. Uma delas é evitar projetar documentos que crescem sem limites. Isso significa que você não deve incorporar pedidos em documentos de clientes. Outra regra é que as coisas que não são "de interesse" por si só (ou não existem por conta própria) provavelmente são melhores sendo incorporadas. Isso sugere que orderItems não merece sua própria coleção e deve simplesmente ser tratado como atributos de pedidos (que é o que eles são, na verdade).

Este exercício exato é abordado no treinamento do desenvolvedor MongoDB, sendo um exemplo bastante típico de design de esquema.

A conclusão é que você deve ter três coleções:

Produtos
Clientes
Pedidos

Os pedidos farão referência a clientes (opcionalmente desnormalizando algumas informações da coleção de clientes) e farão referência a produtos (no array de orderItems que eles conterão).

Outras coleções e campos exatos em todas essas coleções dependem do seu caso de uso específico, mas não vejo um cenário viável para ter menos coleções do que essas três.