Nada se pre-genera
La disponibilidad, igual que el precio, se resuelve en el momento en que se pide, a partir de reglas y excepciones. No hay ningún trabajo de mantenimiento creando filas por adelantado, ni nada que se atrase.
Velocidad y Fiabilidad
Rápido hoy. Igual de rápido con diez veces el tráfico.
Un calendario de diez años cuesta exactamente lo mismo que consultar mañana. Las operaciones masivas corren como un solo viaje de ida y vuelta, no una consulta por fila. Y los índices de los que dependen los reportes y los precios ya existían antes del volumen que los necesitaría.
- Cero pre-generación Un calendario de diez años cuesta exactamente lo mismo que consultar mañana
- 1 viaje de ida y vuelta Las operaciones masivas corren como consultas únicas en lote, verificadas por tests que cuentan el registro real de consultas
- En cola, no bloqueante Las importaciones CSV y los correos de confirmación corren en segundo plano, por fragmentos, sin nunca detener a quien los disparó
Cuatro piezas para mantenerse rápido.
Cada una elimina una forma distinta en que el rendimiento suele degradarse en silencio, hasta que deja de hacerlo.
En lote, nunca fila por fila
Cargar aforos para un calendario, resolver precios en un rango de fechas, o importar un CSV de códigos de stock, todo corre como un número acotado de consultas, sin importar cuántas filas estén involucradas.
Los índices existen antes de necesitarse
Las consultas de reportes, disponibilidad y precios están respaldadas por índices diseñados junto con la propia funcionalidad, no añadidos después de que algo se volvió lento en producción.
El trabajo en segundo plano se mantiene fuera de la solicitud
Las importaciones grandes y los correos de confirmación corren por una cola, así que subir diez mil códigos de stock o enviar un recibo nunca hace esperar a nadie en la página.
Así se demuestra la velocidad, no solo se afirma
Cinco prácticas detrás de por qué la plataforma se mantiene rápida a medida que crecen los datos, no solo cuando arranca pequeña.
- 1
Se afirma un número de consultas, no se asume
El reporte de ventas se prueba con 3 pedidos y otra vez con 30, verificando el mismo número exacto de consultas las dos veces, así que "esto escala" es algo que un test realmente comprueba, no solo una esperanza.
- 2
Una importación CSV corre en fragmentos acotados
Una importación de stock transmite el archivo de 1.000 filas en 1.000 filas, insertando cada fragmento como una sola escritura en lote en lugar de fila por fila, así que un archivo con decenas de miles de líneas nunca mantiene una transacción gigante abierta.
- 3
Un trabajo en cola espera a que la transacción realmente se confirme
Los trabajos ligados a algo recién escrito, un correo de confirmación de pedido, una importación de stock, solo empiezan después de que la transacción de base de datos que creó esos datos realmente se confirmó, nunca antes.
- 4
Un índice se construye para la forma de consulta que sirve
Un índice compuesto sobre organización, estado y fecha de recibo sirve todos los filtros de reporte a la vez; uno separado sobre asunto y estado sirve específicamente las consultas de "quién llegó a este estado en este rango", porque son patrones de acceso genuinamente distintos.
- 5
Un reintento duplicado nunca corrompe los datos
Si un trabajo de importación en cola se reintenta, una verificación de duplicados por fragmento más la propia restricción única de la base de datos evitan que el mismo código de stock se inserte dos veces, así que reintentar siempre es seguro.
Velocidad que se puede verificar, no solo afirmar
La misma prueba de regresión de número de consultas que protege el reporte de ventas, ejecutada con dos volúmenes de pedidos distintos, verificando un número de consultas idéntico las dos veces.
TEST BuildsSalesReportTest.php
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
{
"test": "sales report query count",
"orders_in_range": [
3,
30
],
"queries_executed": [
14,
14
]
}Verificado por test automatizado
Un reporte con 3 pedidos corre exactamente tantas consultas como uno con 3 millones
La forma más común en que un reporte se vuelve lento en silencio es una consulta extra escondida dentro de un bucle, invisible con un puñado de pedidos de prueba y visible recién en producción, a escala. La batería de tests de Tiqory fija el número exacto de consultas para 3 pedidos y vuelve a verificar el mismo número para 30, atrapando una consulta suelta por fila en el instante en que se introduce, no meses después, cuando el historial de pedidos de un cliente ya creció lo suficiente para notarse.
Preguntas frecuentes
No. Nada de la disponibilidad se pre-genera ni se guarda por adelantado; cada fecha y franja se resuelve desde reglas y excepciones en el momento en que se pide, así que una consulta a diez años cuesta lo mismo que una para mañana.
Se procesa en segundo plano, en fragmentos de mil filas, insertados como escrituras en lote en lugar de una por una, y nunca bloquea a quien lo subió de seguir usando el resto del panel.
Un test construye el reporte con 3 pedidos, luego con 30, y verifica que el número exacto de consultas a la base de datos se mantiene idéntico las dos veces. Es una propiedad probada, no una suposición.
No. Una verificación de duplicados por fragmento, respaldada por una restricción única de la base de datos como último resguardo, hace que reintentar un trabajo de importación fallido siempre sea seguro y nunca cree el mismo código de stock dos veces.
Antes. Los índices para las consultas de reportes, disponibilidad y precios se diseñan junto con la funcionalidad que los necesita, como parte de construirla, no se agregan después como una solución cuando una consulta empieza a agotar el tiempo de espera.
Más reservas. Más canales. La misma calma.
Tiqory mantiene disponibilidad, precios, pagos y acceso trabajando juntos mientras tu operación crece. Cuéntanos hacia dónde vas; te mostramos cómo llegar sin volver a empezar.