Replikering af adresser — spejl DAR lokalt

De fleste applikationer kalder et adresse-API ved runtime — brugeren taster, API'et svarer, færdig. Men nogle systemer har brug for alle danske adresser tilgængeligt lokalt: offline-apps, datavarehuse, højtydende pipelines der ikke har råd til round-trip-latens på hvert record. Det er hvad adresse-replikering er til. Denne guide forklarer hvordan DAWA's replikerings-protokol virker og hvordan du holder en lokal kopi synkroniseret efter DAWA lukker den 17. august 2026.

Hvad er adresse-replikering?

Adresse-replikering betyder at vedligeholde en lokal kopi af hele det danske adressedatasæt — alle 2,7 millioner adresser og 1,1 millioner adgangsadresser fra DAR — og holde den opdateret efterhånden som adresser oprettes, ændres og slettes.

DAWA leverede en replikerings-protokol baseret på en hændelsesstream: enhver ændring til en adresse i DAR producerer en nummereret hændelse. En subscriber holder styr på den sidst behandlede hændelse (sekvensnummeret) og henter med jævne mellemrum nye hændelser til at anvende på sin lokale kopi.

Danadresse eksponerer den samme replikerings-protokol, med de samme sekvensnumre fra DAR. Hvis du allerede har en DAWA-replikerings-subscriber, er migration en URL-ændring.

Hvornår har du brug for replikering?

De fleste applikationer har ikke brug for replikering. Du har brug for det når:

• Offline-funktionalitet — din app virker uden netværksforbindelse (field-apps, offline-first mobilapps, indlejrede systemer).
• Højt opslagsvolumen med lav latens — du laver millioner af adresseopslagninger om dagen og round-trip API-latens betyder noget i skala.
• Datavarehus / data lake-integration — du sammenkører danske adresser med andre datasæt i din egen database eller analytiske platform.
• Compliance og revision — du har brug for en tidsstemplet log over enhver adresseændring til regulatoriske formål.
• Adresseberignings-pipeline — du forud-beriger adresser med BBR/vurdering/energimærke-data og cache'r resultaterne lokalt.

Hvis du kun bygger adresse-autocomplete eller validerer en adresse ved checkout, har du ikke brug for replikering. Det hostede API håndterer det.

Hvordan hændelsesstreamen virker

Replikerings-protokollen har to endpoints:

senesteSekvensnummer

GET /replikering/senesteSekvensnummer
→ { "sekvensnummer": 987654 }

Kald dette for at finde det nyeste sekvensnummer. Brug det til at opdage om nye hændelser er tilgængelige (sammenlign med dit gemte "sidst behandlede" nummer).

haendelser — hændelsesstream

GET /replikering/haendelser?sekvensnummerfra=12345&maxantal=1000
→ [
    { "sekvensnummer": 12345, "operation": "Update", "tidspunkt": "2026-06-01T14:32:00Z",
      "entitet": "Adresse", "data": { "id": "0a3f50c8-...", "vejnavn": "..." } },
    ...
  ]

Hent hændelser startende fra et givent sekvensnummer. maxantal begrænser batchstørrelsen (maks 10.000). Hændelser har tre operationer: Insert, Update, Delete.

Entitetstyper inkluderer: Adresse, Adgangsadresse, Postnummer, Vejstykke, NavngivenVej, Kommune, Region, Sogn.

Første indlæsning — bootstrap af din lokale kopi

Ved første kørsel kan du ikke starte fra sekvensnummer 1 og genafspille alle hændelser nogensinde — der er hundredvis af millioner af historiske hændelser. Bootstrappes i stedet med et snapshot:

1. Notér det aktuelle senesteSekvensnummer (kald det N).
2. Download det fulde adressedatasæt-snapshot (tilgængeligt som CSV/JSON via /adresser?format=csv&side=1&per_side=10000 — paginér igennem alle records).
3. Importér snapshot'et ind i din lokale database.
4. Start din hændelsesloop fra sekvensnummer N+1.

Dette sikrer at du ikke misser hændelser der ankommer under snapshot-download.

Polling-løkken

En minimal replikerings-subscriber i pseudokode:

last_seq = indlæs_fra_db("sidst_behandlet_sekvensnummer")

while True:
    latest = GET /replikering/senesteSekvensnummer
    if latest > last_seq:
        hændelser = GET /replikering/haendelser
                         ?sekvensnummerfra={last_seq + 1}
                         &maxantal=1000
        for hændelse in hændelser:
            anvend_hændelse(hændelse)  # Insert/Update/Delete i lokal DB
            last_seq = hændelse["sekvensnummer"]
        gem_i_db("sidst_behandlet_sekvensnummer", last_seq)
    vent(60)  # poll hvert minut

Vigtigt: gem last_seq holdbart (database, ikke hukommelse) så en genstart ikke genafspiller hændelser eller misser dem.

Migration af en DAWA-replikerings-subscriber

Hvis du har en eksisterende DAWA-replikerings-subscriber, er migration ligetil:

1. Skift base-URL: https://api.dataforsyningen.dk → https://api.danadresse.dk
2. Tilføj API-nøgle-header: X-Api-Key: dawa_live_…
3. Dit sekvensnummer er gyldigt. Danadresse bruger de samme DAR-sekvensnumre som DAWA. Din subscriber fortsætter fra præcis det sted den stoppede.

Ingen re-bootstrap, intet re-download af hele datasættet, ingen skemaændringer.

Replikering er en Enterprise-funktion

Danadresses replikerings-API er en del af Enterprise-niveauet. Det sikrer pålidelig infrastruktur (dedikeret kapacitet, SLA, prioriteret support) til de use cases der har brug for det — offline-systemer, datavarehuse og compliance-pipelines er forretningskritiske og fortjener garanteret tilgængelighed.

Hvis du i øjeblikket bruger DAWA-replikering i produktion, kontakt os for at diskutere en Enterprise-migration. Vi tilbyder onboarding-support til storskalerede replikerings-subscribers.