Caching-strategi mot natomrade-API

Hur du minskar latens, kostnad och belastning på vår sida.

Uppdaterad 2026-05-19

Vad ska cachas hur länge?

Datatyp	Cache-TTL	Varför
Postnr → nätägare	30 dagar	Stabil master-data, ändras nästan aldrig
Adress → koordinat (geokod)	90 dagar	OSM uppdateras men individuella adresser stabila
Nätägar-detalj	7 dagar	Företagsinfo ändras sällan
Spotpris current	15 min	Nytt värde varje kvart
Spotpris day-ahead	24 timmar efter ~14:00	Publiceras dagligen
Produktion current	15 min	Nytt värde varje kvart
Listor (alla nätägare etc)	7 dagar	Sällan ändras

Cache-implementation

Redis

import redis, json
r = redis.from_url("redis://localhost")

def cached_lookup(postnr):
    key = f"natomrade:postnr:{postnr}"
    cached = r.get(key)
    if cached:
        return json.loads(cached)
    data = api.lookup_postal(postnr)
    r.set(key, json.dumps(data), ex=30*86400)  # 30 dagar
    return data

HTTP Cache-headers

Vissa endpoints returnerar Cache-Control: public, max-age=.... Använd dem.

CDN

Om du behöver hög-volym + låg latens globalt: lägg en CDN (Cloudflare, Fastly) framför ditt eget API som proxar mot natomrade. Cache-Control-headers respekteras.

Negativ cachning

404 på postnr → cache i max 1 timme. Postnummerregistret uppdateras men sällan.

429 → cache INTE. Det är temporärt. Implementera retry istället.

Invalidation

Sällan nödvändigt eftersom datat är stabilt. Men för säkerhets skull:

def invalidate_natagare(ediel_id):
    r.delete(f"natomrade:natagare:{ediel_id}")
    # plus alla postnr cachade till denna nätägare? Svårt att veta.

Bästa: använd kort nog TTL (7-30 dagar) och låt invalidering ske naturligt.

Mätning

Cache-hit-ratio bör vara > 90% i en stabil app. Om du ligger lägre: - Cache-TTL för kort? - Får du många unika postnr/adresser? - Missar du nyckel-konsistens (case, mellanslag)?