La respuesta correcta dependerá de los instrumentos y mercados en los que se opere, y de si se trata de gestionar órdenes públicas o privadas. Por ejemplo, si tuviera que diseñar para el caso simple, acciones estadounidenses y un mercado público, querría que el tamaño de la cola fuera de cada nivel de precios para poder manejar al menos el volumen máximo diario de, por ejemplo, QQQ. Sé que eso no es de ninguna manera "altamente optimizado", pero el peor momento para que tu brillante y rápido libro tenga un colapso es cuando algo inesperado ha sucedido en alguna parte. Lo mismo ocurre con los rangos de precios: tienes que ser capaz de soportar precios que sean al menos varios órdenes de magnitud más altos que el precio más alto jamás impreso en ese mercado. Tomando de nuevo la renta variable como ejemplo, algunos de los ETFs inversos altamente apalancados tienen el potencial de hacer cosas que nunca hemos visto antes.
Si se trata de pares de divisas, por ejemplo, hay demasiadas maneras de que una serie de acontecimientos políticos puedan hacer estallar el código si se intentan hacer estructuras de datos demasiado ajustadas. Utiliza Hungría o Zimbabue como modelo cuando pienses en esto; es posible que elevar al cuadrado el valor total actual de la oferta monetaria de un país determinado no sea un número lo suficientemente grande para el numerador o denominador futuro de un par de divisas.
Quizás la verdadera respuesta correcta es la que probablemente no quieres: Optimiza tus estructuras de datos para la velocidad utilizando los algoritmos adecuados, pero no intentes optimizarlas para el tamaño si quieres que tu código sobreviva a tiempos interesantes. Puede que incluso quieras utilizar el tamaño máximo que tu plataforma permita cómodamente; si estás negociando algo que podría estar sujeto a la hiperinflación, incluso 64 bits podrían no ser suficientes para un campo de precios.
También depende del modelo de negocio al que se pretenda dar soporte; en algún momento la empresa necesita saber dónde están esos límites y cuándo puede necesitar salir de ciertos mercados antes de que sus propios sistemas fallen de forma catastrófica.
Otra forma de enfocar esto sería mirar el tamaño de los datos de las aplicaciones que hablan con el libro de órdenes. Si planea admitir tamaños de datos más pequeños que los de las aplicaciones de los clientes, entonces querrá protegerse de lo que sucederá cuando llegue un valor más grande de lo esperado. El peor caso podría no ser un volcado del núcleo - podría ser una orden grande llenada a un precio que se desborda y se envuelve. ;-)