Rien n'est pré-généré
La disponibilité, comme la tarification, se résout au moment où elle est demandée, à partir de règles et d'exceptions. Il n'existe aucune tâche de maintenance créant des lignes à l'avance, donc rien sur quoi prendre du retard.
Vitesse et fiabilité
Un calendrier sur dix ans coûte exactement ce que coûte l'interrogation de demain. Les opérations en masse s'exécutent en un seul aller-retour, jamais une requête par ligne. Et les index dont dépendent les rapports et la tarification existaient déjà avant le volume qui en aurait eu besoin.
Chacun élimine une manière différente dont la performance se dégrade habituellement en silence, jusqu'à ce qu'elle ne le fasse plus.
La disponibilité, comme la tarification, se résout au moment où elle est demandée, à partir de règles et d'exceptions. Il n'existe aucune tâche de maintenance créant des lignes à l'avance, donc rien sur quoi prendre du retard.
Charger les réservoirs de capacité pour un calendrier, résoudre les prix sur une plage de dates, ou importer un CSV de codes de stock : tout s'exécute avec un nombre borné de requêtes, quel que soit le nombre de lignes concernées.
Les requêtes de rapports, de disponibilité et de tarification s'appuient sur des index conçus en même temps que la fonctionnalité elle-même, jamais ajoutés plus tard une fois qu'un point est devenu lent en production.
Les gros imports et les e-mails de confirmation passent par une file d'attente, si bien qu'envoyer dix mille codes de stock ou un reçu ne fait jamais attendre personne sur la page.
Cinq pratiques qui expliquent pourquoi la plateforme reste rapide à mesure que les données grandissent, pas seulement au lancement, quand tout est petit.
Le rapport de ventes est testé avec 3 commandes, puis avec 30, en vérifiant exactement le même nombre de requêtes les deux fois, si bien que « ça passe à l'échelle » est quelque chose qu'un test vérifie vraiment, pas juste un espoir.
Un import de stock lit le fichier en flux, 1 000 lignes à la fois, en insérant chaque bloc comme une seule écriture groupée au lieu d'une ligne à la fois, si bien qu'un fichier de dizaines de milliers de lignes ne maintient jamais une transaction géante ouverte.
Les tâches liées à quelque chose qui vient d'être écrit, un e-mail de confirmation de commande, un import de stock, ne démarrent qu'après la validation effective de la transaction qui a créé leurs données, jamais avant.
Un index composite sur organisation, statut et date de reçu sert tous les filtres de rapport à la fois ; un autre, séparé, sur sujet et statut, sert spécifiquement les requêtes « qui a atteint ce statut dans cette période », parce que ce sont réellement des schémas d'accès différents.
Si une tâche d'import en file d'attente est retentée, une vérification de doublon par bloc, associée à la contrainte d'unicité propre à la base de données, empêche le même code de stock d'être inséré deux fois, si bien que réessayer est toujours sans risque.
Le même test de non-régression sur le nombre de requêtes qui protège le rapport de ventes, exécuté à deux volumes de commandes différents, en vérifiant un nombre de requêtes identique les deux fois.
{
"test": "sales report query count",
"orders_in_range": [
3,
30
],
"queries_executed": [
14,
14
]
}La façon la plus courante dont un rapport ralentit en silence, c'est une requête supplémentaire cachée dans une boucle, invisible avec une poignée de commandes de test et visible seulement en production, à l'échelle. La suite de tests de Tiqory fixe le nombre exact de requêtes pour 3 commandes et revérifie ce même nombre pour 30, ce qui attrape une requête par ligne égarée dès son introduction, pas des mois plus tard, quand l'historique de commandes d'un client aura assez grandi pour qu'on le remarque.
Non. Rien dans la disponibilité n'est pré-généré ou stocké à l'avance ; chaque date et chaque créneau se résolvent à partir de règles et d'exceptions au moment où ils sont demandés, si bien qu'une requête à dix ans coûte la même chose qu'une requête pour demain.
Il se traite en arrière-plan, par blocs de mille lignes, insérées en écritures groupées plutôt qu'une à la fois, sans jamais empêcher la personne qui l'a envoyé d'utiliser le reste du panneau.
Un test construit le rapport avec 3 commandes, puis avec 30, et vérifie que le nombre exact de requêtes en base de données reste identique les deux fois. C'est une propriété prouvée, pas une supposition.
Non. Une vérification de doublon par bloc, appuyée par une contrainte d'unicité en base de données comme dernier filet, garantit que réessayer une tâche d'import échouée est toujours sans risque et ne crée jamais deux fois le même code de stock.
Avant. Les index pour les requêtes de rapports, de disponibilité et de tarification sont conçus en même temps que la fonctionnalité qui en a besoin, dans le cadre même de sa construction, jamais ajoutés plus tard en correctif une fois qu'une requête commence à expirer.
Tiqory garde disponibilité, tarifs, paiements et accès parfaitement synchronisés à mesure que votre activité grandit. Dites-nous où vous allez ; nous vous montrons comment y arriver sans repartir de zéro.