Construire un moteur de crawling distribuéOrchestrer en Node.js, exécuter sur Crawlbase

Le crawling web cesse d'être un problème de scraping bien avant de devenir un problème de parsing. La difficulté ne réside pas dans le téléchargement du HTML ni dans l'extraction des données. Elle consiste à coordonner des millions de requêtes sur des milliers de domaines sans perdre de travail, sans crawler deux fois la même page, et sans passer votre temps à maintenir des pools de proxys et une infrastructure de navigateurs au lieu de construire votre application.

C'est là que l'architecture change. Un crawler de production a besoin de files d'attente, de workers, de retries, de rotation de proxys, de rendu JavaScript, de gestion anti-bot et d'une frontière de crawl durable capable de s'étendre en continu sans revisiter les mêmes URLs. En bref, vous résolvez un problème de systèmes distribués.

La meilleure approche consiste à séparer l'orchestration du crawl de son exécution. Votre application décide quoi crawler, à quelle profondeur et quoi extraire. L'infrastructure de crawling gère la mise en file d'attente, la concurrence, les retries, le rendu et la fiabilité réseau, laissant votre moteur concentré sur la logique métier plutôt que sur l'infrastructure.

Dans cet article, nous allons construire un moteur de crawling distribué en Node.js qui suit exactement cette conception. Le moteur possède la politique de crawl, la déduplication des URLs, le parsing du HTML, le stockage des résultats et l'expansion récursive de la frontière, tandis que Crawlbase fournit la couche d'exécution distribuée via l'Enterprise Crawler de Crawlbase et la Crawling API de Crawlbase. L'Enterprise Crawler agit comme une file d'attente managée et une flotte de workers qui livrent les résultats de crawl de manière asynchrone à un webhook, tandis que la Crawling API offre un chemin de récupération inline pour les requêtes sensibles à la latence. Le résultat est un crawler qui passe à l'échelle avec l'infrastructure de Crawlbase tout en restant assez petit pour être compris en quelques centaines de lignes de code.

Chaque implémentation présentée ici provient du dépôt GitHub compagnon. Clonez-le, suivez chaque étape d'implémentation en parallèle de l'article, et vous obtiendrez une base prête pour la production que vous pourrez étendre avec votre propre logique d'extraction, votre backend de stockage et vos politiques de crawl.

Concevoir un crawler distribué

Tout crawler distribué résout en continu quatre problèmes :

1. Gérer la frontière de crawl : décider quoi crawler ensuite.
2. Exécuter les crawls : récupérer les pages de manière fiable à grande échelle.
3. Traiter les résultats : extraire et stocker les données utiles.
4. Étendre le crawl : transformer les liens nouvellement découverts en futurs jobs de crawl.

Ces responsabilités sont étroitement liées. Chaque crawl terminé produit à la fois des données et de nouvelles URLs. Ces URLs passent par la politique de crawl, intègrent la frontière et finissent par être récupérées à leur tour, formant une boucle de rétroaction continue.

La frontière de crawl

La frontière est la mémoire du crawler pour le travail en attente. Chaque URL découverte est normalisée, confrontée à la politique de crawl, dédupliquée et planifiée pour le crawl. Sans frontière gérée, les crawls récursifs revisitent rapidement les mêmes pages ou s'égarent hors de leur périmètre prévu.

L'exécution du crawl

Récupérer des pages à grande échelle est avant tout un problème d'infrastructure. Cela exige la coordination des workers, des retries, la rotation de proxys, le rendu navigateur et la gestion anti-bot avant même que votre parser ne voie le HTML. Construire et opérer cette infrastructure est souvent plus complexe que le crawler lui-même.

Le traitement des résultats

Les crawls terminés doivent alimenter un pipeline de traitement indépendant où les pages sont parsées, les données structurées extraites et les résultats persistés. Séparer la récupération du traitement rend les deux systèmes plus faciles à maintenir et à faire évoluer.

L'expansion récursive

Chaque page traitée produit de nouveaux liens. Après avoir passé les contrôles de profondeur, de domaine et de déduplication, ces liens deviennent de nouveaux jobs de crawl et réintègrent la frontière. Cette boucle de rétroaction récursive se poursuit jusqu'à ce qu'il ne reste plus aucune page à visiter dans le périmètre.

Le moteur que nous construisons possède la frontière, la politique de crawl, le parsing, le stockage et l'expansion récursive. Crawlbase fournit la file d'attente distribuée, la flotte de workers, les retries, le rendu navigateur, la rotation de proxys et l'infrastructure anti-bot. Cette séparation garde le moteur concentré sur la logique applicative plutôt que sur l'infrastructure de crawling.

Ce que nous allons construire

Un petit service Express et un ensemble de scripts qui forment ensemble un crawler autonome :

• Un script de configuration exécuté une seule fois crée une file Crawler nommée, liée à votre webhook.
• Un script de seed pousse les URLs de départ dans la file d'attente.
• Crawlbase crawle chaque URL et envoie le résultat en POST à votre webhook.
• Le webhook parse la page, stocke un enregistrement, découvre des liens et repousse dans la file les liens du périmètre qui n'ont pas encore été vus.

Le résultat est un crawler qui passe à l'échelle avec la concurrence de Crawlbase plutôt qu'avec celle de votre serveur, et dont vous pouvez comprendre le fonctionnement en quelques centaines de lignes de code.

Vue d'ensemble de l'architecture

Le flux est une boucle. Le script de seed amorce le moteur, qui pousse les URLs dans l'Enterprise Crawler. Le Crawler est la pièce distribuée : il détient la file d'attente, exécute les crawls à la concurrence configurée à travers le réseau de proxys de Crawlbase, et gère les retries et la résolution anti-bot face aux sites web cibles. Quand un crawl se termine, Crawlbase renvoie la page en POST au webhook du moteur. Le parser du moteur produit un enregistrement pour le stockage et une liste de liens sortants, qui repassent par les contrôles de déduplication et de profondeur vers la prochaine série de pushes.

Crawlbase possède la récupération, la concurrence, les retries et l'infrastructure proxy/anti-bot. Le moteur possède la politique de crawl (ce qui est dans le périmètre, à quelle profondeur) et le sort des données. Le diagramme principal ci-dessus montre aussi l'arête en pointillés : la Crawling API utilisée de manière synchrone pour des récupérations ponctuelles de pages uniques quand vous avez besoin d'un résultat inline plutôt qu'à travers la file d'attente.

Préparer le projet

Maintenant que l'architecture est posée, faisons tourner le projet en local. Le dépôt compagnon contient l'implémentation complète utilisée tout au long de cet article. Nous travaillerons depuis le projet final/ tout en nous référant aux jalons incrémentaux sous steps/ à mesure que nous construisons chaque composant.

Vous aurez besoin de :

• Node.js 18 ou plus récent (le script de configuration utilise le fetch natif).
• Un compte Crawlbase pour obtenir vos tokens de requête.
• Un endpoint webhook accessible publiquement. Pour le développement local, exposez votre serveur Express avec Cloudflare Tunnel (cloudflared) ou ngrok, puis faites pointer CALLBACK_URL vers https://<your-public-host>/webhook.

Clonez le dépôt et installez le projet depuis le répertoire final/ :

git clone https://github.com/ScraperHub/building-a-distributed-crawling-engine.git
cd building-a-distributed-crawling-engine/final
npm install
cp .env.example .env

Ensuite, éditez .env avec votre token Crawlbase et votre URL de callback publique. Dans la suite de l'article, chaque étape d'implémentation correspond directement à un jalon sous steps/, tandis que final/ contient toujours le projet complet exécutable. Le README du dépôt inclut une table de correspondance article-code pour chaque section.

Étape 1 : centraliser la configuration

Le moteur commence par une source unique de vérité pour sa configuration. Plutôt que de disperser les secrets et les valeurs de politique de crawl à travers le code, tout est chargé depuis des variables d'environnement et validé au démarrage. Si une valeur requise comme le token Crawlbase manque, le moteur échoue immédiatement au lieu d'échouer plus tard pendant un crawl.

L'implémentation complète se trouve dans final/src/config.js dans le dépôt compagnon.

const config = {
  crawlbaseToken: required('CRAWLBASE_TOKEN'),
  crawlerName: process.env.CRAWLER_NAME || 'distributed-engine',
  callbackUrl: process.env.CALLBACK_URL || '',
  port: Number(process.env.PORT || 3000),
  maxDepth: Number(process.env.MAX_DEPTH || 2),
  allowedDomains: (process.env.ALLOWED_DOMAINS || '')
    .split(',')
    .map((domain) => domain.trim().toLowerCase())
    .filter(Boolean),
};

La plupart de ces valeurs définissent la politique de crawl du moteur plutôt que son infrastructure. MAX_DEPTH limite jusqu'où le crawler peut s'étendre récursivement, tandis que ALLOWED_DOMAINS restreint le crawl aux sites que vous autorisez explicitement. Le même CRAWLBASE_TOKEN authentifie à la fois l'Enterprise Crawler et la Crawling API : un seul identifiant suffit donc au moteur pour communiquer avec Crawlbase.

La configuration en place, l'étape suivante consiste à créer le crawler distribué qui exécutera nos jobs de crawl.

Étape 2 : créer la file d'attente distribuée

Chez Crawlbase, la file d'attente distribuée est l'Enterprise Crawler : une file managée et une flotte de workers qui acceptent des URLs, les crawlent de manière asynchrone et livrent les résultats soit à un webhook, soit à Cloud Storage. Nous utiliserons la livraison par webhook en fournissant un callback_url à la création du crawler.

La logique de configuration est implémentée dans final/src/setup-crawler.js. La Management API attend le token Crawlbase dans le chemin de l'URL plutôt que dans la query string, le script construit donc l'endpoint en conséquence.

const endpoint = `https://api.crawlbase.com/crawler/${config.crawlbaseToken}`;
const response = await fetch(endpoint, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    name: config.crawlerName,
    callback_url: config.callbackUrl,
  }),
});

Créez le crawler une seule fois :

npm run setup

Une fois le crawler lié à votre webhook, ajouter du travail à la file revient à une requête Crawling API standard avec deux paramètres supplémentaires. crawler identifie la file cible, tandis que callback=true indique à Crawlbase de traiter la requête de manière asynchrone au lieu de retourner la page immédiatement. La requête renvoie un identifiant de requête (rid) dès que l'URL est acceptée dans la file, ce qui permet au crawl réel de se dérouler en arrière-plan.

La logique de push est implémentée dans final/src/crawlbase-client.js.

async function pushToCrawler(url, depth) {
  const response = await api.get(url, {
    crawler: config.crawlerName,
    callback: true,
    callbackHeaders: `X-Crawl-Depth|${depth}`,
  });

  // Surface auth/quota errors instead of silently dropping the URL.
  if (response.statusCode !== 200) {
    throw new Error(`Crawler push failed (${response.statusCode}): ${response.body}`);
  }

  // The push response is the small JSON envelope { "rid": "..." }, but it is
  // not served with a JSON content-type, so parse the body ourselves.
  const parsed = response.json || parseRid(response.body);
  return parsed && parsed.rid;
}

Deux détails d'implémentation méritent d'être notés. D'abord, bien que la réponse du push contienne une charge JSON, elle n'est pas renvoyée avec un content type JSON : le helper parse donc le corps de la réponse au lieu de compter sur une désérialisation automatique. Ensuite, callbackHeaders garde le moteur sans état. La profondeur de crawl courante est attachée à la requête sous X-Crawl-Depth, que Crawlbase renvoie en écho lors de la livraison du webhook. Cela permet au moteur de retrouver la profondeur de crawl sans maintenir son propre état de requêtes.

Le même helper est utilisé par le script de seed, implémenté dans final/src/seed.js, pour mettre en file l'ensemble initial d'URLs.

for (const url of SEED_URLS) {
  if (!shouldCrawl(url, 0)) {
    console.log(`Skipped (filtered or duplicate): ${url}`);
    continue;
  }
  const rid = await pushToCrawler(url, 0);
  console.log(`Queued ${url} -> rid ${rid}`);
}

Exécuter npm run seed affiche une ligne Queued <url> -> rid <rid> pour chaque seed accepté. À ce stade, le crawler distribué tourne. Les URLs vivent désormais dans la file de Crawlbase, et les premiers résultats de crawl vont commencer à arriver sur le webhook que nous allons implémenter maintenant.

Étape 3 : traiter les résultats de crawl avec un webhook

Une fois que le crawler commence à traiter les URLs, le moteur a besoin d'un moyen de recevoir les résultats. Chaque crawl terminé est livré au callback_url configuré plus tôt. La page HTML arrive comme corps de la requête, tandis que les métadonnées telles que pc_status, original_status, rid, url et les éventuels callback headers personnalisés sont envoyées comme en-têtes HTTP.

L'implémentation du webhook se trouve dans final/src/server.js. Deux détails comptent ici. D'abord, Crawlbase livre les réponses compressées en gzip : le serveur utilise donc express.raw() pour recevoir le corps de la requête comme Buffer, qu'Express décompresse de manière transparente. Ensuite, les accusés de réception du webhook doivent être aussi rapides que possible : accusez réception immédiatement, traitez après l'envoi de la réponse.

app.use(express.raw({ type: '*/*', limit: '10mb' }));

app.post('/webhook', (req, res) => {
  // The monitoring bot probes this endpoint to detect outages. Acknowledge
  // it as a no-op - it carries no real crawl result to process. Crawlbase
  // expects a 2xx with an empty body, so end the response without content.
  if ((req.headers['user-agent'] || '').includes('Crawlbase Monitoring Bot')) {
    return res.status(200).end();
  }

  const pcStatus = Number(req.headers['pc_status']);
  const rid = req.headers['rid'];
  const url = req.headers['url'];
  const depth = Number(req.headers['x-crawl-depth'] || 0);

  const html = req.body.toString('utf8');
  res.status(200).end();

  if (pcStatus !== 200 || !rid || !url) {
    return;
  }

  setImmediate(() => handleResult({ rid, url, depth, html }));
});

Le handler s'appuie aussi sur pc_status plutôt que sur l'original_status du site cible. Un pc_status de 200 indique que Crawlbase a mené le crawl à bien après avoir appliqué les retries ou la gestion anti-bot nécessaires : les requêtes en échec peuvent donc simplement être ignorées par le moteur.

Remarquez que le traitement réel se déroule dans setImmediate(), après que la réponse a déjà été accusée. Cela garde le webhook réactif quelle que soit la quantité de parsing ou de stockage à venir, et permet à Crawlbase de continuer à livrer de nouveaux résultats de crawl sans attendre la fin du traitement en aval.

À ce stade, le moteur reçoit les résultats de crawl, mais il n'en fait encore rien d'utile. L'étape suivante consiste à parser chaque page, extraire les données structurées, découvrir de nouveaux liens et les réinjecter dans le crawler.

Étape 4 : extraire les données et étendre la frontière

C'est ici que le crawler devient autonome. Chaque page livrée au webhook produit deux sorties : un enregistrement structuré qui peut être stocké, et un nouvel ensemble de liens qui peuvent devenir de futurs jobs de crawl. La frontière se situe entre ces deux étapes et garantit que le crawl reste borné, déterministe et exempt de travail en double.

L'implémentation de la frontière se trouve dans final/src/frontier.js.

function shouldCrawl(rawUrl, depth) {
  if (depth > config.maxDepth) {
    return false;
  }
  const url = normalize(rawUrl);
  if (!url || !isAllowed(url) || seen.has(url)) {
    return false;
  }
  seen.add(url);
  return true;
}

Le helper shouldCrawl joue le rôle de gardien du moteur. Chaque URL découverte est normalisée, confrontée aux domaines autorisés, validée contre la profondeur de crawl maximale et marquée comme vue avant d'être réadmise dans le crawl. Cette seule fonction fait respecter le périmètre du crawler, garantit la terminaison et évite le travail en double.

Une fois qu'une page passe par le webhook, le moteur extrait ses données, persiste le résultat et évalue chaque lien sortant pour la prochaine vague de crawl. La logique d'extraction et de stockage est implémentée dans final/src/extract.js, tandis que l'orchestration se déroule dans le handler du webhook dans final/src/server.js.

async function handleResult({ rid, url, depth, html }) {
  const { record, links } = extract(html, url);
  save(rid, { rid, url, depth, crawledAt: new Date().toISOString(), ...record });

  let queued = 0;
  for (const link of links) {
    if (shouldCrawl(link, depth + 1)) {
      try {
        await pushToCrawler(link, depth + 1);
        queued += 1;
      } catch (error) {
        console.error(`Failed to queue ${link}: ${error.message}`);
      }
    }
  }
  console.log(`[${rid}] depth=${depth} url=${url} queued=${queued} new links`);
}

Chaque lien sortant passe par la frontière avant de pouvoir devenir un nouveau job de crawl. Les URLs valides sont immédiatement repoussées dans l'Enterprise Crawler, tandis que les doublons, les domaines hors périmètre et les pages au-delà de la profondeur configurée sont écartés. Le moteur n'attend jamais que ces pages soient crawlées ; il les met simplement en file et continue de traiter le résultat courant. Crawlbase gère l'exécution distribuée, et le webhook reçoit la prochaine page terminée quand elle est prête.

Cette boucle de rétroaction récursive est le cœur de l'architecture. Chaque crawl terminé génère plus de travail jusqu'à ce qu'il ne reste plus de nouvelles URLs à découvrir dans le périmètre, ce qui permet au moteur d'étendre le crawl en continu sans maintenir son propre pool de workers ni sa propre file de crawl.

Le cycle de vie complet du crawl

À ce stade, chaque pièce du moteur est en place. Avec votre tunnel en marche et CALLBACK_URL pointant vers lui, le crawl entier démarre avec seulement trois commandes :

npm run setup   # once: create the crawler and bind it to your webhook
npm start       # start the webhook consumer
npm run seed    # enqueue the initial URLs

À partir de là, le moteur tourne de manière autonome. Les URLs de seed sont mises en file, Crawlbase les traite de manière asynchrone, les pages terminées sont livrées au webhook, les données structurées sont extraites et stockées, et chaque lien nouvellement découvert est évalué avant d'être repoussé dans la file. Le cycle se répète jusqu'à ce qu'il ne reste plus de pages à crawler dans le périmètre.

Parce que le moteur ne fait qu'orchestrer le workflow, le débit est déterminé par la concurrence des workers de Crawlbase plutôt que par les ressources de votre application. Passer le crawl à l'échelle n'exige ni processus workers supplémentaires ni modifications du moteur lui-même ; il s'agit de laisser Crawlbase traiter plus de jobs de crawl en parallèle. À mesure que le crawl progresse, vous pouvez suivre l'activité via les logs du serveur et la collection grandissante d'enregistrements JSON sous le répertoire results/.

L'architecture prend aussi en charge la récupération synchrone de pages quand un crawl en file n'est pas approprié. Le helper fetchInline dans final/src/crawlbase-client.js utilise la Crawling API pour récupérer une page unique immédiatement avec le même token Crawlbase. En pratique, l'Enterprise Crawler est le bon choix pour les crawls asynchrones à haut volume, tandis que la Crawling API convient mieux aux requêtes sensibles à la latence, comme des recherches côté utilisateur ou des agents IA récupérant du contexte à la demande.

Considérations pour la production

L'implémentation que nous avons construite est volontairement petite pour que l'architecture reste facile à comprendre. Avant de l'utiliser en production, quelques points méritent d'être renforcés.

• Déplacez la frontière vers un stockage partagé. L'exemple stocke l'ensemble seen en mémoire, ce qui limite la déduplication à un seul processus et la fait disparaître au redémarrage. Pour plusieurs instances du moteur ou des crawls de longue durée, déplacez la frontière vers Redis ou un autre datastore partagé indexé par URLs normalisées.
• Gérez les secrets hors de l'application. L'exemple charge le token Crawlbase depuis .env pour le développement local. En production, injectez les identifiants via le gestionnaire de secrets de votre plateforme au lieu de les stocker dans des fichiers de configuration.
• Gardez le webhook rapide et fiable. Le webhook doit accuser réception immédiatement et reporter le traitement coûteux après l'envoi de la réponse. Les endpoints lents ou indisponibles déclenchent des retries de livraison : protéger l'endpoint avec un secret partagé ou des callback headers personnalisés améliore à la fois la fiabilité et la sécurité.
• Envisagez Crawlbase Cloud Storage pour le traitement asynchrone. Les webhooks sont idéaux pour traiter les résultats de crawl dès qu'ils sont disponibles, mais ils ne sont pas la seule option de livraison. Quand l'Enterprise Crawler est configuré pour utiliser Cloud Storage, chaque crawl terminé est automatiquement persisté sans nécessiter de webhook, et votre application récupère les résultats à son propre rythme via la Storage API. Cela convient bien au traitement par lots, aux environnements où exposer un endpoint HTTPS n'est pas pratique, ou aux workflows qui bénéficient d'une URL permanente pour chaque page crawlée. Consultez la documentation sur le mode de livraison Storage pour les détails.
• Surveillez la croissance de la file. Les Enterprise Crawlers appliquent des limites de concurrence, de capacité de file et de débit de push pour garder les crawls prévisibles. Si vos producteurs dépassent vos consommateurs, surveillez la taille de la file et mettez en pause ou purgez les crawls hors de contrôle via la Management API avant qu'ils ne consomment des ressources inutiles. À mesure que votre charge grandit, vous pouvez demander des limites de concurrence ou de débit de push plus élevées depuis le tableau de bord du support Crawlbase.
• Choisissez le bon mode de rendu. Commencez avec un token Normal chaque fois que possible. Si une cible dépend fortement du rendu côté client ou renvoie des pages de challenge, passez au JavaScript Crawler et utilisez des paramètres de rendu comme page_wait ou ajax_wait pour attendre le contenu dynamique avant l'extraction.
• Respectez les limites du crawl. Gardez le crawler dans les domaines que vous possédez ou que vous êtes autorisé à consulter, respectez le robots.txt et les conditions d'utilisation de chaque site le cas échéant, et configurez des limites de crawl raisonnables pour éviter de générer du trafic inutile.

Conclusion

Nous avons construit un moteur de crawling distribué en séparant l'orchestration du crawl de son exécution. Le moteur possède la politique de crawl, la déduplication des URLs, le parsing, le stockage et l'expansion récursive de la frontière, tandis que Crawlbase fournit la file d'attente distribuée, la flotte de workers, les retries, le rendu navigateur et l'infrastructure de proxys. Cette séparation garde l'application petite, facile à comprendre et concentrée sur la logique qui la rend unique.

L'implémentation d'exemple privilégie volontairement la simplicité sur la préparation à la production. À mesure que vos charges grandissent, vous pouvez remplacer la frontière en mémoire par Redis, persister les résultats de crawl dans une base de données, ou exécuter plusieurs instances sans état du moteur derrière la même file distribuée sans changer l'architecture globale.

Questions fréquentes

Quand utiliser l'Enterprise Crawler plutôt que la Crawling API ?

Les deux services résolvent des problèmes différents. Utilisez l'Enterprise Crawler pour les crawls asynchrones à grande échelle où vous avez besoin de mise en file, de retries, de concurrence et de livraison par webhook ou Cloud Storage. Utilisez la Crawling API quand vous avez besoin d'une page immédiatement, par exemple pour répondre à une requête côté utilisateur ou donner du contexte en temps réel à un agent IA. Une bonne règle générale : la file pour le débit, la Crawling API pour les requêtes à faible latence.

Dois-je exposer un webhook public ?

Non. Cet article utilise un webhook parce que c'est la manière la plus réactive de traiter les résultats de crawl dès qu'ils sont disponibles. Vous pouvez aussi configurer un Enterprise Crawler pour livrer les résultats vers Crawlbase Cloud Storage et les récupérer plus tard via la Storage API. C'est souvent mieux adapté aux workflows de traitement par lots ou aux environnements où exposer un endpoint HTTPS public n'est pas pratique.

Quand utiliser un token JavaScript plutôt qu'un token Normal ?

Commencez avec un token Normal chaque fois que possible : il est plus rapide et plus économique. Si le site cible rend son contenu côté client, renvoie une coquille HTML vide ou présente des challenges anti-bot qui exigent un navigateur, passez à une requête JavaScript et utilisez au besoin des paramètres de rendu comme page_wait ou ajax_wait.

Comment faire traiter les URLs plus vite par le crawler ?

Le moteur lui-même est volontairement léger ; il ne fait qu'orchestrer le crawl. Le débit global est déterminé par la concurrence de l'Enterprise Crawler plutôt que par les ressources de votre application. Si votre charge exige un débit supérieur à vos limites actuelles, vous pouvez demander une augmentation via le tableau de bord du support.

Puis-je exécuter plusieurs instances de ce moteur ?

Oui. L'architecture est conçue pour le passage à l'échelle horizontal. Le seul composant qui doit changer est la frontière en mémoire. Remplacer l'ensemble local seen par un stockage partagé comme Redis permet à plusieurs consommateurs de webhook de coordonner l'état du crawl tout en partageant la même file de l'Enterprise Crawler.

NZ

Neil Zamora

Architecte senior · Crawlbase

Architecte senior chez Crawlbase, axé sur les systèmes derrière le crawling à grande échelle : rotation de proxys, résilience anti-bot et les API qui masquent cette complexité.

IK

Ian Kalvin

Ingénieur support technique · Crawlbase

Ingénieur support technique chez Crawlbase, il écrit depuis la première ligne de ce qui casse réellement en production, sur les configurations de scraping et de proxys.