Schaal
Grote woningfeeds: wat er verandert boven een paar duizend objecten
Vanaf een paar duizend objecten houdt de normale aanpak op te werken. Wat er dan omvalt, en welke verwerking een grote feed nodig heeft.
Kleine feeds werken volgens één patroon: haal alles op, gooi de oude gegevens weg, zet de nieuwe erin. Dat is makkelijk te bouwen en te begrijpen, en het werkt prima tot een bepaald volume. Daarboven vraagt een feed een andere verwerking.
Waar de grens ligt
De grens ligt niet bij een vast aantal objecten. Hij is bereikt wanneer één volledige synchronisatie langer duurt dan het interval waarop hij draait.
Draait de synchronisatie elk uur en duurt hij vijfenveertig minuten, dan lijkt er niets aan de hand. Groeit het aanbod, of wordt de andere kant een keer traag, dan duurt hij zeventig minuten — en start de volgende terwijl de vorige nog loopt. Twee processen schrijven dan tegelijk dezelfde gegevens weg, en de uitkomst is onvoorspelbaar. Zo gaat een feed "ineens" stuk zonder dat er iets veranderd is behalve het volume.
Wat er dan omvalt
- Alles-in-één-keer laden. Een verwerking die de complete feed in het geheugen inleest, werkt tot het bestand een bepaalde omvang bereikt, en houdt er daarna abrupt mee op.
- Timeouts halverwege. De verbinding valt weg na tienduizend van de vijftienduizend objecten. Zonder herstelpunt begint de volgende poging weer bij nul en haalt hij het einde nooit.
- Alles weggooien en opnieuw vullen. Zolang de nieuwe gegevens nog niet binnen zijn, staat je website leeg. Bij een kleine feed duurt dat twee seconden en ziet niemand het. Bij een grote feed staat je aanbod een half uur offline.
- De ontvangende kant knijpt af. Portalen accepteren maar een bepaald aantal verzoeken per minuut. Ga je daaroverheen, dan word je geweigerd — en of dat netjes wordt afgehandeld, verschilt per koppeling.
- Eén afwijkend object stopt de rest. Bij een kleine feed vind je dat object snel terug. Bij vijftienduizend panden weet je zonder melding niet eens welk object het is.
Wat je in plaats daarvan bouwt
Alleen verwerken wat er gewijzigd is. Bijhouden wanneer je voor het laatst gesynchroniseerd hebt, en alleen ophalen wat sindsdien is aangepast. Dat brengt de meeste feeds terug van uren naar minuten.
Per object verwerken, niet per batch. Een object dat niet door de controle komt, wordt overgeslagen en gemeld. De andere veertienduizend gaan gewoon door.
Voorkomen dat twee runs elkaar overlappen. Een lopende synchronisatie houdt de volgende tegen tot hij klaar is.
Kunnen hervatten. Valt de verbinding weg bij object tienduizend, dan gaat de volgende poging daar verder in plaats van opnieuw te beginnen.
Vervangen in plaats van legen. Nieuwe gegevens ernaast opbouwen en pas omzetten als ze compleet zijn, zodat er nooit een moment is waarop de site leeg is.
Meten wat er doorkomt. Aantallen per run, en een melding als het aantal objecten fors afwijkt van gisteren. Bij deze omvang is dat de enige manier om stille uitval op tijd te zien.
Als je hier hulp bij nodig hebt
Ik neem dit soort koppelingen vaak over: gebouwd toen het aanbod kleiner was, en onbetrouwbaar geworden nu het gegroeid is.
Neem contact op
Wil je een grote feed betrouwbaar draaiend krijgen?
Noem om hoeveel objecten het gaat, uit welk systeem en waar het naartoe moet. Je krijgt binnen een werkdag antwoord.
Het meeste begint met een korte mail - info@pawon.nl.