Κλιμάκωση του Tracking API: Πώς να διαχειριστείτε τον όγκο της περιόδου αιχμής, τα όρια αιτημάτων και τη μαζική εγγραφή

Για την κλιμάκωση ενός API παρακολούθησης κατά την περίοδο αιχμής, τοποθετήστε την καταχώριση αποστολών πίσω από μια ανθεκτική ουρά, επιβάλετε τα όρια του παρόχου σε όλους τους workers, χρησιμοποιήστε ομαδοποίηση μόνο εντός των τεκμηριωμένων ορίων και επεξεργαστείτε ασύγχρονα τις ενημερώσεις παρακολούθησης. Αντιμετωπίστε τη διεκπεραιωτική ικανότητα καταχώρισης, την κίνηση επαναλήψεων και την επεξεργασία webhook ως ξεχωριστά προβλήματα χωρητικότητας. Η προσθήκη περισσότερων workers χωρίς έλεγχο των εξερχόμενων αιτημάτων μπορεί να αυξήσει τον περιορισμό ρυθμού αντί να μειώσει την εκκρεμότητα.

Για τις ομάδες μηχανικής που συνδέουν ένα σύστημα διαχείρισης παραγγελιών, μια πλατφόρμα αποθήκης ή ένα backend ηλεκτρονικού εμπορίου με μια υπηρεσία παρακολούθησης, ο στόχος δεν είναι απλώς η αποστολή περισσότερων αιτημάτων. Είναι η καταχώριση των αποστολών μέσα σε ένα καθορισμένο χρονικό διάστημα, η διατήρηση των ενημερώσεων κατά τις αιχμές κίνησης και η ανάκαμψη από αστοχίες χωρίς τη δημιουργία διπλής εργασίας.

Υπολογίστε τον φόρτο με βάση τις αποστολές, τα αιτήματα και τις ενημερώσεις

Ο ημερήσιος όγκος αποστολών δεν επαρκεί για τον υπολογισμό μεγέθους μιας ενοποίησης. Μια αποθήκη μπορεί να αποδεσμεύει τους περισσότερους αριθμούς παρακολούθησης μέσα σε ένα σύντομο χρονικό παράθυρο αποστολής, ενώ οι ενημερώσεις κατάστασης φτάνουν καθ’ όλη τη διάρκεια της ημέρας. Μοντελοποιήστε αυτούς τους φόρτους ξεχωριστά.

• Εισερχόμενες καταχωρίσεις: Νέες εγγραφές αποστολών που εισέρχονται στο σύστημά σας ανά δευτερόλεπτο ή λεπτό, συμπεριλαμβανομένων εισαγωγών και αιχμών αποδέσμευσης από την αποθήκη.
• Εξερχόμενη κίνηση API: Αιτήματα καταχώρισης, αναζητήσεις, διορθώσεις, κλήσεις συμφωνίας και επαναλήψεις.
• Εισερχόμενη κίνηση ενημερώσεων: Παραδόσεις και επαναπαραδόσεις webhook, όπου υποστηρίζονται από τον πάροχο.
• Εργασία downstream: Εγγραφές στη βάση δεδομένων, ειδοποιήσεις πελατών, συμβάντα αναλυτικών στοιχείων και αλλαγές κατάστασης παραγγελιών που προκαλούνται από κάθε ενημέρωση.

Ορίστε έναν εσωτερικό στόχο καταχώρισης, όπως τον μέγιστο αποδεκτό χρόνο μεταξύ της λήψης ενός αριθμού παρακολούθησης και της επιβεβαίωσης της καταχώρισής του. Διατηρήστε τον ξεχωριστό από την επικαιρότητα της παρακολούθησης: η επιτυχής καταχώριση δεν σημαίνει ότι είναι ήδη διαθέσιμη μια σάρωση από τον μεταφορέα.

Υπολογίστε την αποτελεσματική χωρητικότητα καταχώρισης

Για ένα endpoint καταχώρισης με περιορισμό αιτημάτων, μια χρήσιμη σχέση σχεδιασμού είναι:

Registration capacity = permitted requests per second × average records per request × successful-record fraction

Αυτό αποτελεί εκτίμηση σχεδιασμού και όχι εγγύηση του παρόχου. Υποθέτει ότι τα όρια αιτημάτων είναι ο δεσμευτικός περιορισμός. Οι ποσοστώσεις βάσει εγγραφών, το μέγεθος του φορτίου, η καθυστέρηση και τα κοινόχρηστα όρια λογαριασμού ενδέχεται να επιβάλλουν χαμηλότερο ανώτατο όριο.

Μόνο για λόγους παραδείγματος, υποθέστε ότι μια ενοποίηση επιτρέπεται να εκτελεί δύο αιτήματα καταχώρισης ανά δευτερόλεπτο και στέλνει κατά μέσο όρο 30 εγγραφές σε κάθε αίτημα. Η ονομαστική χωρητικότητά της είναι 60 εγγραφές ανά δευτερόλεπτο πριν από αστοχίες και άλλους περιορισμούς. Αν οι εισερχόμενες καταχωρίσεις ανέρχονται κατά μέσο όρο σε 80 εγγραφές ανά δευτερόλεπτο κατά τη διάρκεια μιας παρατεταμένης αιχμής, η ουρά αυξάνεται κατά περίπου 20 εγγραφές ανά δευτερόλεπτο. Αυτά τα στοιχεία είναι υποθετικά και δεν αποτελούν όρια του 17TRACK.

Υπολογίστε επίσης τη χωρητικότητα ανάκαμψης. Αν οι νέες αφίξεις συνεχίζονται με ρυθμό λ και η αποτελεσματική χωρητικότητα επεξεργασίας είναι μ, μια υφιστάμενη εκκρεμότητα B εγγραφών χρειάζεται περίπου B / (μ − λ) δευτερόλεπτα για να εκκαθαριστεί όταν μ > λ. Αν η χωρητικότητα επεξεργασίας δεν υπερβαίνει τις αφίξεις, η εκκρεμότητα δεν θα εκκαθαριστεί υπό αυτές τις συνθήκες.

Επιβεβαιώστε τι περιορίζει πραγματικά ο πάροχος

Ένα όριο ρυθμού και ένα όριο χρήσης επιλύουν διαφορετικά προβλήματα. Το όριο ρυθμού ελέγχει πόσο γρήγορα μπορούν να υποβληθούν αιτήματα ή εγγραφές. Ένα όριο χρήσης μπορεί να ελέγχει πόση δραστηριότητα παρακολούθησης μπορεί να καταναλώσει ένας λογαριασμός κατά τη διάρκεια μιας περιόδου χρέωσης ή δικαιώματος χρήσης. Η παραμονή κάτω από το ένα δεν αποδεικνύει συμμόρφωση με το άλλο.

Πριν ορίσετε τον αριθμό των workers, επιβεβαιώστε τα παρακάτω στην τεκμηρίωση του παρόχου και στους όρους του λογαριασμού σας:

• Αν τα όρια εφαρμόζονται ανά λογαριασμό, κλειδί API, endpoint, διεύθυνση IP ή άλλο πεδίο.
• Αν η μονάδα μέτρησης είναι ένα αίτημα, μια εγγραφή παρακολούθησης ή άλλη λειτουργία.
• Αν τα endpoints μοιράζονται ένα όριο ή διαθέτουν ανεξάρτητα δικαιώματα χρήσης.
• Ο μέγιστος αριθμός εγγραφών και το μέγεθος φορτίου που επιτρέπονται σε ένα αίτημα.
• Πώς επηρεάζουν τη χρήση οι διπλές υποβολές, οι μη έγκυρες εγγραφές και οι επαναλήψεις.
• Αν οι αποκρίσεις παρέχουν πληροφορίες περιορισμού ρυθμού ή οδηγίες επανάληψης.
• Πώς διαφέρει η εξάντληση ποσόστωσης από τον προσωρινό περιορισμό ρυθμού.

Για μια ενοποίηση με το 17TRACK, χρησιμοποιήστε την επίσημη σελίδα Tracking API και την τεκμηρίωση API ως σημεία εκκίνησης για αυτήν τη διαμόρφωση. Επιβεβαιώστε τη συμπεριφορά του σχετικού endpoint και τα όρια του λογαριασμού πριν από την ανάπτυξη. Οι χωρητικότητες του παραδείγματος σε αυτόν τον οδηγό αποτελούν απεικονίσεις αρχιτεκτονικής και όχι δηλώσεις σχετικά με τα δικαιώματα χρήσης, τα μεγέθη παρτίδων ή τις εγγυήσεις υπηρεσίας του 17TRACK.

Τοποθετήστε μια ανθεκτική ουρά μεταξύ της επεξεργασίας παραγγελιών και της καταχώρισης

Μην αναγκάζετε την ολοκλήρωση αγοράς ή την ολοκλήρωση εργασιών αποθήκης να περιμένει μέχρι ένας πάροχος παρακολούθησης να αποδεχτεί μια καταχώριση. Αποθηκεύστε την αποστολή τοπικά, καταγράψτε την εργασία καταχώρισης με ανθεκτικό τρόπο και αφήστε τους workers παρασκηνίου να χειριστούν την υποβολή.

Μια πρακτική ροή είναι:

1. Αποθηκεύστε την αποστολή και την πρόθεσή της για καταχώριση. Χρησιμοποιήστε transactional outbox ή ισοδύναμο σχεδιασμό, ώστε να μην αποθηκεύσετε την παραγγελία χάνοντας παράλληλα την εργασία παρασκηνίου.
2. Επικυρώστε και κανονικοποιήστε τις εισόδους. Διατηρήστε τους αριθμούς παρακολούθησης ως συμβολοσειρές, συμπεριλαμβανομένων των αρχικών μηδενικών. Εφαρμόστε κανονικοποίηση ανά μεταφορέα μόνο όταν δικαιολογείται.
3. Ελέγξτε αν υπάρχει ήδη καταχώριση. Χρησιμοποιήστε μια σταθερή ταυτότητα κατάλληλη για τον πάροχο και το μοντέλο δεδομένων σας.
4. Τοποθετήστε σε ουρά τις επιλέξιμες εγγραφές. Αποθηκεύστε τον αριθμό προσπαθειών, τον χρόνο της επόμενης επιτρεπόμενης επανάληψης και αρκετό πλαίσιο για διάγνωση.
5. Υποβάλετε μέσω κοινόχρηστου περιοριστή. Αποκτήστε χωρητικότητα αμέσως πριν από το εξερχόμενο αίτημα.
6. Αποθηκεύστε τα αποτελέσματα σε επίπεδο εγγραφής. Διαχωρίστε την επιβεβαιωμένη επιτυχία, την αποτυχία που επιδέχεται επανάληψη, την οριστική απόρριψη και τα αμφίσημα αποτελέσματα.

Μια ουρά απορροφά μια αιχμή· δεν δημιουργεί χωρητικότητα παρόχου. Αν η παλαιότερη επιλέξιμη εγγραφή συνεχίζει να παλιώνει, διερευνήστε το χάσμα μεταξύ ρυθμού άφιξης και χωρητικότητας επεξεργασίας αντί να αυξήσετε απλώς τον αριθμό των workers.

Συντονίστε τα όρια μεταξύ των workers

Οι ανεξάρτητοι workers δεν πρέπει να υποθέτουν ο καθένας ότι μπορεί να καταναλώσει ολόκληρο το διαθέσιμο όριο του λογαριασμού. Χρησιμοποιήστε έναν συντονισμένο περιοριστή ρυθμού ή έναν dispatcher που κατανέμει έναν κοινόχρηστο προϋπολογισμό αιτημάτων. Συμπεριλάβετε σε αυτόν τον προϋπολογισμό τις προγραμματισμένες εισαγωγές, τα λειτουργικά scripts και τις εργασίες συμφωνίας.

Ο ρυθμός και η ταυτόχρονη εκτέλεση είναι διαφορετικοί έλεγχοι. Ο περιοριστής ελέγχει πόσο συχνά ξεκινούν τα αιτήματα· ένα όριο ταυτόχρονης εκτέλεσης ελέγχει πόσα παραμένουν σε εξέλιξη. Και τα δύο είναι χρήσιμα όταν αυξάνεται η καθυστέρηση του παρόχου. Η αύξηση της ταυτόχρονης εκτέλεσης μπορεί να βοηθήσει έναν φόρτο που περιορίζεται από την καθυστέρηση, αλλά δεν μπορεί να παρακάμψει ένα εξερχόμενο όριο ρυθμού.

Χρησιμοποιήστε μαζική καταχώριση χωρίς να χάσετε τον έλεγχο σε επίπεδο εγγραφής

Όπου ένα endpoint υποστηρίζει πολλές εγγραφές ανά αίτημα, η ομαδοποίηση μπορεί να μειώσει την επιβάρυνση των αιτημάτων. Δεν μειώνει απαραίτητα τη χρήση βάσει εγγραφών και η μεγαλύτερη επιτρεπόμενη παρτίδα δεν είναι πάντα η καλύτερη λειτουργική επιλογή.

Δημιουργήστε παρτίδες χρησιμοποιώντας δύο εναύσματα: μέγιστο αριθμό εγγραφών και μέγιστο χρόνο αναμονής. Υποβάλετε όταν επιτευχθεί οποιοδήποτε από τα δύο. Έτσι, οι περίοδοι υψηλής κίνησης γεμίζουν αποτελεσματικά τις παρτίδες, χωρίς να αναγκάζονται οι ροές χαμηλού όγκου να περιμένουν επ’ αόριστον.

• Τηρείτε τόσο τα όρια φορτίου όσο και τα όρια αριθμού εγγραφών. Τα προαιρετικά μεταδεδομένα μπορούν να κάνουν παρτίδες ίδιου μεγέθους πολύ διαφορετικές σε byte.
• Διατηρήστε ένα εσωτερικό manifest παρτίδας. Καταγράψτε ποιες τοπικές ταυτότητες αποστολών υποβλήθηκαν και συσχετίστε σωστά κάθε επιστρεφόμενο αποτέλεσμα.
• Εξετάστε τα αποτελέσματα σε επίπεδο εφαρμογής. Μια επιτυχής απόκριση HTTP δεν αποδεικνύει από μόνη της ότι έγινε αποδεκτή κάθε εγγραφή.
• Επαναλάβετε μόνο τις εγγραφές που χρειάζονται επανάληψη. Η επανεκτέλεση επιτυχημένων εγγραφών δημιουργεί περιττή κίνηση και μπορεί να έχει συνέπειες στη χρήση.
• Κατευθύνετε τις οριστικές αποτυχίες επικύρωσης προς διόρθωση. Ένα αμετάβλητο μη έγκυρο φορτίο δεν πρέπει να κυκλοφορεί στην ουρά επαναλήψεων.

Ένα timeout είναι ιδιαίτερα σημαντικό: ο πάροχος μπορεί να έχει αποδεχτεί το αίτημα παρότι ο client σας δεν έλαβε την απόκριση. Επισημάνετε αυτό το αποτέλεσμα ως αμφίσημο. Επιλύστε το μέσω υποστηριζόμενου μηχανισμού idempotency, τεκμηριωμένου κανόνα διπλής καταχώρισης ή αναζήτησης συμφωνίας όπου είναι διαθέσιμη. Μην υποθέτετε ότι μια εγγραφή που έληξε λόγω timeout απέτυχε.

Διαχωρίστε τη ζωντανή κίνηση από τις ιστορικές εισαγωγές

Ένα backfill δεν πρέπει να καταναλώνει όλη τη χωρητικότητα που απαιτείται για τις νεοαποσταλμένες αποστολές. Χρησιμοποιήστε ξεχωριστές ουρές με στάθμιση προγραμματισμού ή ρητές δεσμεύσεις χωρητικότητας. Επιτρέψτε στις εισαγωγές να χρησιμοποιούν την εφεδρική χωρητικότητα, διατηρώντας παράλληλα μια ελάχιστη κατανομή για τις ζωντανές καταχωρίσεις. Εφαρμόστε παλαίωση ή άλλο κανόνα δικαιοσύνης, ώστε οι εγγραφές χαμηλότερης προτεραιότητας να επεξεργάζονται τελικά.

Κάντε τις επαναλήψεις ελεγχόμενες, καθυστερημένες και περιορισμένες

Το HTTP 429 σημαίνει «Too Many Requests». Το RFC 6585 καθορίζει ότι μια απόκριση 429 μπορεί να περιλαμβάνει κεφαλίδα Retry-After. Το RFC 9110 ορίζει ότι η τιμή αυτής της κεφαλίδας είναι είτε ημερομηνία HTTP είτε καθυστέρηση σε δευτερόλεπτα. Ένας client πρέπει να αναλύει και τις δύο μορφές αντί να υποθέτει ότι επιστρέφεται πάντα ακέραιος.

Όταν παρέχεται έγκυρη καθυστέρηση επανάληψης, μην επαναλάβετε πριν αυτή λήξει. Όταν απουσιάζουν οδηγίες επανάληψης, χρησιμοποιήστε εκθετική οπισθοχώρηση με ανώτατο όριο και jitter: αυξήστε σταδιακά την καθυστέρηση μεταξύ των προσπαθειών και προσθέστε τυχαιότητα, ώστε οι workers να μην επαναλάβουν όλοι μαζί. Οι επαναλήψεις πρέπει να περνούν από τον ίδιο εξερχόμενο περιοριστή με τις αρχικές προσπάθειες.

Κατηγοριοποιήστε τις αστοχίες πριν από την επανάληψη:

• Περιορισμός ρυθμού: Καθυστερήστε την επηρεαζόμενη εργασία και μειώστε την πίεση αποστολής εντός του σχετικού πεδίου ορίου.
• Παροδικές αστοχίες δικτύου ή διακομιστή: Επαναλάβετε εντός μιας περιορισμένης πολιτικής, λαμβάνοντας υπόψη τα αμφίσημα αποτελέσματα εγγραφής.
• Αστοχίες ελέγχου ταυτότητας ή εξουσιοδότησης: Ειδοποιήστε και暂停στε την επηρεαζόμενη εργασία μέχρι να διορθωθούν τα διαπιστευτήρια ή τα δικαιώματα.
• Αστοχίες επικύρωσης: Διορθώστε ή απομονώστε την εγγραφή αντί να την αποστείλετε ξανά αμετάβλητη.
• Εξαντλημένο όριο χρήσης: Ακολουθήστε την τεκμηριωμένη λύση για τον λογαριασμό αντί να το αντιμετωπίσετε ως σύντομη αιχμή κίνησης.

Ορίστε τόσο όριο προσπαθειών όσο και μέγιστη ηλικία επαναλήψεων. Μετακινήστε τα εξαντλημένα στοιχεία σε dead-letter queue με αιτιολογία, υπεύθυνο και διαδικασία επανάληψης. Διαφορετικά, παλιές αστοχίες μπορεί να καταναλώνουν αθόρυβα τη χωρητικότητα που προορίζεται για νέες αποστολές.

Κλιμακώστε ανεξάρτητα την εισαγωγή webhook

Όπου ο πάροχος προσφέρει κατάλληλα webhook, αυτά μπορούν να μειώσουν την επαναλαμβανόμενη αναζήτηση κατάστασης. Δημιουργούν επίσης ξεχωριστό εισερχόμενο φόρτο, ο οποίος πρέπει να παραμένει διαθέσιμος κατά τις αιχμές ενημερώσεων.

Διατηρήστε το endpoint λήψης εστιασμένο: επικυρώστε το αίτημα χρησιμοποιώντας τον τεκμηριωμένο μηχανισμό του παρόχου, αποθηκεύστε μόνιμα το συμβάν και επιστρέψτε την απαιτούμενη επιβεβαίωση. Επεξεργαστείτε ασύγχρονα τις αλλαγές παραγγελιών, τα αναλυτικά στοιχεία και τα μηνύματα πελατών. Μην επιβεβαιώνετε τη λήψη πριν από τη μόνιμη αποδοχή, αν αυτό ενέχει κίνδυνο απώλειας του συμβάντος.

Σχεδιάστε τους consumers ώστε να ανέχονται διπλές παραδόσεις, εκτός αν η σύμβαση του παρόχου ορίζει ρητά το αντίθετο. Προτιμήστε ένα τεκμηριωμένο σταθερό αναγνωριστικό συμβάντος για deduplication. Αν δεν υπάρχει, σχεδιάστε και δοκιμάστε προσεκτικά μια σύνθετη ταυτότητα: η χρήση μόνο μιας ετικέτας κατάστασης μπορεί να συγχωνεύσει διαφορετικά συμβάντα σε ένα.

Προστατευτείτε επίσης από ενημερώσεις εκτός σειράς. Αποθηκεύστε το ιστορικό συμβάντων ξεχωριστά από την παράγωγη τρέχουσα κατάσταση αποστολής. Εφαρμόστε τις τεκμηριωμένες χρονικές σημάνσεις συμβάντων και τους κανόνες μετάβασης όπου είναι διαθέσιμοι· μην υποθέτετε ότι η σειρά άφιξης είναι η σειρά συμβάντων ή ότι οι καταστάσεις αποστολών σχηματίζουν μια καθολικά αυξανόμενη ακολουθία.

Διατηρήστε τη συμφωνία στοχευμένη και περιορισμένη ως προς τον ρυθμό. Μπορεί να διερευνήσει ύποπτα κενά παράδοσης ή αμφίσημες καταχωρίσεις, αλλά η επιθετική αναζήτηση για κάθε αποστολή μπορεί να αναδημιουργήσει τον εξερχόμενο φόρτο που τα webhook προορίζονταν να αποφύγουν.

Δοκιμάστε την ανάκαμψη, όχι μόνο τη μέγιστη διεκπεραιωτική ικανότητα

Εκτελέστε δοκιμές φόρτου στα δικά σας στοιχεία χρησιμοποιώντας έναν προσομοιωτή παρόχου. Συντονίστε τις δοκιμές που στέλνουν σημαντική κίνηση σε έναν ενεργό πάροχο και παραμείνετε εντός των εξουσιοδοτημένων ορίων. Μια επιτυχημένη δοκιμή πρέπει να αποδεικνύει ότι το σύστημα επιστρέφει στην κανονική λειτουργία μετά από διακοπή, όχι απλώς ότι αποδέχεται μια μεγάλη αιχμή.

• Επαναλάβετε μια αιχμή τύπου αποθήκης, ακολουθούμενη από συνεχιζόμενη κανονική κίνηση.
• Εισαγάγετε αποκρίσεις περιορισμού ρυθμού, αυξημένη καθυστέρηση και προσωρινές αστοχίες διακομιστή.
• Προσομοιώστε μερική απόρριψη παρτίδας και timeout μετά από αποδοχή στην πλευρά του διακομιστή.
• Παραδώστε διπλά και εκτός σειράς συμβάντα webhook.
• Διακόψτε την πρόσβαση στη βάση δεδομένων και επαληθεύστε ότι τα μη αποδεκτά συμβάντα δεν επιβεβαιώνονται εσφαλμένα.
• Εκτελέστε backfill παράλληλα με ζωντανές καταχωρίσεις και ελέγξτε τη δικαιοσύνη.
• Επαναλάβετε στοιχεία dead-letter χωρίς παράκαμψη των ελέγχων ρυθμού.

Παρακολουθήστε την ηλικία της παλαιότερης επιλέξιμης καταχώρισης, την καθυστέρηση αποδοχής, το ποσοστό επιτυχίας σε επίπεδο εγγραφής, τη συχνότητα περιορισμού ρυθμού, τον όγκο επαναλήψεων, την καθυστέρηση επεξεργασίας webhook και την αύξηση των dead-letter στοιχείων. Το βάθος της ουράς από μόνο του δεν επαρκεί: μια μεγάλη ουρά μπορεί να εκκαθαριστεί γρήγορα, ενώ μια μικρή ουρά μπορεί να περιέχει μερικές επανειλημμένα αποτυγχάνουσες, κρίσιμες για την επιχείρηση αποστολές.

Πριν από την περίοδο αιχμής, αναθέστε τη λειτουργική ευθύνη. Η μηχανική πρέπει να έχει την ευθύνη των ελέγχων αποστολής και των εργαλείων ανάκαμψης· ο υπεύθυνος ενοποίησης πρέπει να επιβεβαιώσει τα δικαιώματα χρήσης του παρόχου· οι λειτουργίες πρέπει να καθορίσουν ποιες αποστολές έχουν προτεραιότητα. Τεκμηριώστε πότε πρέπει να διακόπτονται οι εισαγωγές, να ζητείται πρόσθετη χωρητικότητα ή να διερευνώνται ελλείπουσες ενημερώσεις. Ο ισχυρότερος σχεδιασμός είναι αυτός που παραμένει προβλέψιμος όταν η κίνηση υπερβαίνει την άμεση χωρητικότητα επεξεργασίας του.

Συχνές ερωτήσεις

Η προσθήκη API keys θα αυξήσει τη διεκπεραιωτική ικανότητα;

Όχι απαραίτητα. Πολλά keys μπορεί να μοιράζονται ένα όριο σε επίπεδο λογαριασμού. Επιβεβαιώστε το πεδίο του ορίου και την επιτρεπόμενη προσέγγιση κλιμάκωσης με τον πάροχο. Μην χρησιμοποιείτε εναλλαγή keys για να παρακάμπτετε περιορισμούς.

Πρέπει κάθε καταχώριση να χρησιμοποιεί τη μεγαλύτερη δυνατή παρτίδα;

Όχι. Οι μεγαλύτερες παρτίδες μπορούν να βελτιώσουν την αποδοτικότητα των αιτημάτων, αλλά η αναμονή για να γεμίσουν αυξάνει την καθυστέρηση σε χαμηλό όγκο. Χρησιμοποιήστε ένα τεκμηριωμένο ανώτατο όριο μεγέθους μαζί με χρονοδιακόπτη αποστολής και, στη συνέχεια, ρυθμίστε τα με βάση τη μετρημένη καθυστέρηση αποδοχής και τη συμπεριφορά αστοχιών.

Πώς μπορούν να αποτραπούν οι διπλές καταχωρίσεις μετά από timeout;

Χρησιμοποιήστε ανθεκτική τοπική ταυτότητα αποστολής και την τεκμηριωμένη συμπεριφορά idempotency ή χειρισμού διπλών καταχωρίσεων του παρόχου. Αν το αποτέλεσμα παραμένει αβέβαιο, πραγματοποιήστε συμφωνία όπου υποστηρίζεται πριν από την επανάληψη. Το τοπικό deduplication από μόνο του δεν μπορεί να αποδείξει αν ένα απομακρυσμένο αίτημα πέτυχε.

Σημαίνει η επιτυχής καταχώριση ότι οι πληροφορίες παρακολούθησης είναι ενημερωμένες;

Όχι. Η αποδοχή καταχώρισης, η διαθεσιμότητα συμβάντος από τον μεταφορέα, η επεξεργασία από τον πάροχο και η δική σας επεξεργασία ενημερώσεων είναι ξεχωριστά στάδια. Μετρήστε τα ξεχωριστά, ώστε μια καθυστερημένη σάρωση από τον μεταφορέα να μην εκληφθεί ως εκκρεμότητα καταχώρισης.

Πότε πρέπει μια ομάδα να ζητήσει περισσότερη χωρητικότητα από τον πάροχο;

Ζητήστε την όταν οι προβλεπόμενες αφίξεις και ο απαιτούμενος χρόνος ανάκαμψης υπερβαίνουν την επαληθευμένη διαθέσιμη χωρητικότητα, αφού αφαιρεθούν οι αποτρέψιμες επαναλήψεις, οι διπλές υποβολές και η αναποτελεσματική ομαδοποίηση. Ένα μεγαλύτερο όριο δεν θα διορθώσει έναν μπλοκαρισμένο consumer ή ένα bottleneck στη βάση δεδομένων, επομένως εντοπίστε πρώτα τον δεσμευτικό περιορισμό.

Πηγές

• 17TRACK Tracking API — επίσημο σημείο εισόδου για την προσφορά API.
• 17TRACK API documentation — αναφορά για τον έλεγχο των απαιτήσεων ενοποίησης, της συμπεριφοράς των endpoint και των ισχυόντων περιορισμών αιτημάτων.
• RFC 6585, Section 4: 429 Too Many Requests — σημασιολογία περιορισμού HTTP και προαιρετικές οδηγίες Retry-After.
• RFC 9110, Section 10.2.3: Retry-After — μορφές HTTP-date και delay-seconds.
• RFC 9110, Section 9.2.2: Idempotent Methods — ζητήματα επανάληψης όταν το αποτέλεσμα ενός αιτήματος είναι αβέβαιο.