Bulk-IP-Lookup-API: Rate-Limit-Architektur
Eine Bulk-IP-Lookup-API löst viele Adressen in einer einzigen Anfrage auf, statt pro Adresse einen Aufruf zu senden. Die Architektur drumherum hängt von drei Randbedingungen ab: der maximalen Batch-Größe, dem Anfragebudget, das Sie ausgeben dürfen, und davon, wie gut Sie vermeiden, dieselbe Frage zweimal zu stellen. Dieser Beitrag beschreibt einen praxistauglichen Entwurf und nutzt den Bulk-Endpunkt von ipto für die konkreten Zahlen.
Was der Bulk-IP-Lookup-Endpunkt akzeptiert
Der Bulk-Lookup von ipto ist ein POST an /v1/ip/bulk mit einem JSON-Array von IP-Strings. Die Anfrage nimmt bis zu 100 Adressen entgegen, Duplikate werden vor der Verarbeitung entfernt, und die Antwort ist ein Objekt mit der IP-Adresse als Schlüssel. Jeder Eintrag hat die Form eines einzelnen Lookup-Ergebnisses mit Land, Stadt, ASN, Organisation sowie den Feldern is_vpn, is_tor, is_abuser, is_datacenter und Bogon. Bulk ist ein Feature der kostenpflichtigen Tarife, verfügbar in Pro und Enterprise, während der Free-Tarif Einzelabfragen mit 1.000 Anfragen pro Tag ohne Registrierung abdeckt. Das aktuelle Anfrageformat finden Sie in der API-Dokumentation.
Wichtig ist die Abrechnung: Bulk wird pro Element berechnet. Ein Batch aus 100 Adressen zählt mit 100 gegen Ihr Tagesbudget, genau wie 100 einzelne Abfragen. Batching dehnt Ihr Kontingent also nicht. Es spart Roundtrips, Verbindungsaufbau und clientseitige Orchestrierung, und das ist oft der eigentliche Engpass, wenn Sie eine Logdatei oder eine Kundenliste anreichern.
Die Pipeline am Budget ausrichten
Da jede Adresse Budget verbraucht, ist die günstigste Anfrage die, die Sie nie senden. Beginnen Sie mit Filtern. Private und reservierte Adressen haben nie eine aussagekräftige Geolokalisierung, und Sie können sie lokal verwerfen oder mit dem Bogon-IP-Checker klassifizieren, bevor sie etwas kosten. Deduplizieren Sie die verbleibende Menge, denn Produktionslogs werden von wenigen wiederkehrenden Besuchern, Crawlern und NAT-Gateways dominiert. Ein Hash-Set vor dem Batcher ist meist die Änderung mit dem größten Ertrag.
Ergänzen Sie dann einen Cache mit der Adresse als Schlüssel und einer Time-to-Live, die dazu passt, wie schnell sich die für Sie relevanten Daten ändern. Zuordnungen von Land und ASN bleiben lange stabil, daher sind Tage vertretbar. Reputations-Flags ändern sich schneller, denn die Threat-Feeds von ipto werden alle 6 Stunden aktualisiert und die IP- und ASN-Datensätze täglich. Ein Urteil länger als ein paar Stunden zu cachen, erzeugt also Veralterung, ohne viel zu sparen. Halten Sie nach Möglichkeit getrennte TTLs pro Feld vor, oder cachen Sie das gesamte Ergebnis mit der kürzeren TTL.
- Bogon- und offensichtlich ungültige Eingaben lokal herausfiltern.
- Innerhalb des Jobs und gegen den Cache deduplizieren.
- Die verbleibenden Adressen in Gruppen von höchstens 100 aufteilen.
- Chunks mit begrenzter Nebenläufigkeit senden statt alle auf einmal.
- Ergebnisse mit der Adresse als Schlüssel in den Cache und den Zielspeicher schreiben.
Nebenläufigkeit, Backoff und das Tagesfenster
Ein Tagesbudget ist ein festes Fenster, der zu vermeidende Fehlerfall ist also, es mitten in einem Job aufzubrauchen. Schätzen Sie die Kosten vor dem Start: Die Zahl der eindeutigen Nicht-Bogon-Adressen ist die Zahl der Anfragen, die der Job verbraucht. Übersteigt sie, was heute noch übrig ist, teilen Sie den Job auf mehrere Fenster auf, priorisieren Sie zuerst die wertvollsten Adressen oder weichen Sie nur für die riskantesten auf Einzelabfragen aus. Speichern Sie den Fortschritt, damit ein neu gestarteter Job beim letzten abgeschlossenen Chunk fortsetzt statt von vorn.
Setzen Sie auf moderate Nebenläufigkeit. Eine Handvoll paralleler Chunks reicht fast immer, da jeder Chunk bereits 100 Abfragen enthält, und unbegrenztes Fan-out erschwert nur die Fehleranalyse. Bei einem vorübergehenden Fehler oder einer Antwort wegen überschrittenen Budgets wiederholen Sie mit exponentiellem Backoff und Jitter, und behandeln ein erschöpftes Budget als Signal, anzuhalten und später fortzufahren, nicht als etwas, das in einer engen Schleife wiederholt wird. Machen Sie jeden Schreibvorgang idempotent, damit ein wiederholter Chunk keine Zeilen doppelt einfügen kann.
Bulk oder Einzelabfrage wählen
Für Echtzeitpfade wie ein Anmeldeformular oder einen Checkout nutzen Sie eine Einzelabfrage pro Ereignis. Die Latenz ist gering, der Cache fängt Wiederholungen ab, und Sie verbrauchen Budget nur für Adressen, die tatsächlich ankommen. Bulk ist für Offline-Arbeit: eine Tabelle nachfüllen, einen Tag Logs bewerten oder eine Allowlist prüfen. Geht es Ihnen um Risikobewertung statt um reine Anreicherung, führt der Fraud-Score-Checker IP-, E-Mail-, Telefon- und User-Agent-Signale zu einem einzigen Score von 0 bis 100 zusammen und kann mehrere separate Aufrufe ersetzen. Einen ausführlicheren Vergleich der Limits kostenloser Tarife verschiedener Anbieter finden Sie in unserem Vergleich der Rate Limits kostenloser Tarife.
Protokollieren Sie schließlich Ihre eigene Nutzung. Erfassen Sie die pro Job verbrauchten Anfragen, die Cache-Trefferquote und den Anteil der als Bogon oder Duplikat verworfenen Adressen. Diese drei Zahlen verraten Ihnen lange vor einem Budgetalarm, ob die Architektur funktioniert.
Bevor Sie einen großen Batch skripten, probieren Sie ein paar Adressen von Hand aus: Die ASN-Abfrage zeigt, welchem Netzwerk eine Range gehört, die Ihnen in Ihren Logs immer wieder begegnet. Oft lässt sich so ein ganzes Netzwerk mit einer Entscheidung behandeln statt mit Tausenden Einzelabfragen.