De meeste gedistribueerde systemen leveren software nog op de oude manier: iemand met credentials pusht een binary naar elke machine. Dat werkt zolang je elke host bezit. Het hapert zodra een knooppunt op andermans netwerk staat, achter een trage uplink, of bij een operator die nooit jouw deploy-sleutels mag krijgen.
Op PolitiCap — het politieke marktplatform van 3DN — draaien regionale exchange-nodes (een ECN, electronic communication network) in verschillende steden en landen. Sommige hosts zijn van ons. Andere misschien niet. Dus draaiden we de default om: nodes pullen; de hub pusht nooit.
Dit is het engineeringverhaal van die pull-structuur: software, TLS-certificaten, databaseschema, marktcatalogus en trade-batches — plus de communicatiegrafen die productie eerlijk houden.
De regel in één zin
Als een machine niet volledig onder 3DN-controle staat, mag de hub er geen shell naartoe openen. Het knooppunt authenticeert naar buiten, vraagt wat er is veranderd, en past updates op eigen schema toe. Dat is digitale soevereiniteit voor infrastructure: elke regio houdt de sleutel van de eigen deur.
Vijf loops, geen dikke updater
Elk regionaal API-proces is gewone managed hosting-compute: één service, één publiek gezicht voor zijn stad. Daarbinnen draaien vijf achtergrondloops naast HTTP — gelijktijdige werkeenheden (goroutines in Go), geen nachtelijke “deploy window.”
- Hello — periodieke geauthenticeerde ping zodat de hub weet dat het knooppunt leeft en welke softwarebuild het draait.
- Binary-pull — als de hub een nieuwer artifact aankondigt: download naast de draaiende binary, cryptografische hash, atomische swap, proces vervangen.
- Certificaat-pull — TLS-paar voor de hostname ophalen wanneer fingerprints afwijken of verloop nadert.
- Catalogus-delta — incrementele ticker- en composietrijen (geen volledige databasedump).
- Trade-batch — lokale fills in een outbox; het knooppunt post batches naar de hub. Idempotente sleutels voorkomen dubbele ingest. Geen holdings-replay — alleen fill-feiten.
Schemamigraties reizen met de binary: bij processtart past het knooppunt pending expand-only SQL toe die het meeneemt. De hub kan schemaversies ook via de API beschrijven; de duurzame regel blijft “schema met software,” niet “SQL in andermans database duwen.”
Waarom pull trage links overleeft
Eén van onze edge-nodes zit op een verre VPS met een trage route terug naar de hub. Een HTTP-timeout van twee minuten leek prima op het LAN en faalde elke keer op die uplink. De fix was niet “harder pushen vanaf de hub,” maar:
- De kleine versiecheck (korte timeout) scheiden van de bulkdownload (geen overall body-timeout — wel een header-timeout zodat een dode hub snel faalt).
- Gzip op de lijn zodat de payload kleiner is; de hash blijft die van het ruwe artifact.
- Stagen naast de draaiende binary (geen willekeurige temp), zodat operators een echt pad kunnen volgen tijdens een lange transfer — en het stagingbestand verdwijnt na succes of mislukte verificatie.
- Mislukte pulls in minuten opnieuw proberen, niet eens per uur.
Als een knooppunt wel van ons is, mogen we de eerste binary nog met de hand zetten. Daarna houdt dezelfde pull-loop hem actueel. Onbeheerde of half-beheerde hosts zien überhaupt geen push-kanaal.
Wat de hub écht bewaart
De hub is geen magische CD-pipeline op de wereld. Het is een kleine, saaie store:
- Een versiestempel en platformspecifieke binaries die nodes ophalen.
- Een certificaatstore gevuld door onze normale issuance — nodes pullen hun eigen hostname-materiaal.
- Databasetabellen voor laatste hello, gerapporteerde softwareversie, schema-watermark, catalogusgeneratie, en een archief van gesyndiceerde fills.
Ops-zichtbaarheid gaat naar een metrics-dashboard: welk hostname welke build draait, of hij achter loopt op de hub-latest, en wanneer hij voor het laatst hello zei. High-availability hub-replica’s telden dezelfde stad dubbel totdat we gauges opnieuw opbouwden vanuit de database in plaats van “wat dit proces het laatst zag.”
Waarom dit bij 3DN past
3DN levert infrastructure en managed hosting met een voorkeur voor operators die controle willen zonder chaos. Diezelfde voorkeur zit in de producten van de 3DN family — work · money · politics — waar PolitiCap de politics-poot is. Regionale markten blijven alleen betrouwbaar als updatepaden expliciet, auditbaar en veilig zijn op links die we niet volledig bezitten.
We bouwen dat pad in open engineeringzin: GitLab-gevolgde wijzigingen, expand-only migraties, hash-geverifieerde artifacts, en pull-only beleid voor onbeheerde nodes. Geen romantiek over zero-touch magie. Wel production-gewoonten die een trage VPS en een multi-city-kaart overleven.
Takeaways
- Pull is een security boundary, geen mode. Vertrouw je de host niet, push er niet naartoe.
- Splits de klokken: softwareversie, schemaversie en catalogusgeneratie zijn verschillende dingen. Ze mengen dwingt tot full dumps of gebroken upgrades.
- Trage WAN is een requirement, geen uitzondering. Timeouts horen op de control-plane probe, niet op het multi-megabyte body.
- Batch wat kan: trade-outboxes en catalogusdelta’s houden chatter klein en retries veilig.
- Observeer vanuit duurzame state: metrics die alleen in process memory leven liegen zodra je twee hub-replica’s hebt.
Draai je multi-region API’s op 3DN compute — of ontwerp je eigen ECN-achtige randen — begin bij de communicatiegraaf, niet bij het deploy-script. De pijlen vertellen wie eerst mag spreken.
Geef een reactie