Request Deduplication: wat is het, methoden en werkingsmechanismen

Wat is deduplicatie van aanvragen?

Request Deduplication — is een techniek die voorkomt dat meerdere identieke aanvragen naar dezelfde gegevensbron worden uitgevoerd in hetzelfde tijdsvenster. In plaats van 10 identieke HTTP-aanvragen te sturen, stuurt het systeem er één en wachten de andere 9 op het resultaat.

Het probleem van dubbele aanvragen is bijzonder acuut in mobiele apps met op status gebaseerde architectuur (MVVM, MVI, Redux). Wanneer meerdere waarnemers zich in korte tijd op dezelfde gegevens abonneren, start elk zijn eigen aanvraag, wat overmatige belasting creëert. Volgens Uber Engineering (2024) is tot 18% van alle aanvragen in Uber mobiele clients dubbele, en deduplicatie op de client verminderde hun aantal met een factor 4.

Deduplicatie is niet hetzelfde als cachen. De cache bewaart het resultaat van een aanvraag na uitvoering. Deduplicatie voorkomt overmatige aanvragen voor en tijdens de uitvoering. Na voltooiing van de aanvraag treedt de cache in werking en wordt het resultaat opgeslagen.

class DeduplicatorT(
    private val source: suspend () -> T
) {
    private val inFlight = ConcurrentHashMap<String, Deferred<T>>()

    suspend fun get(key: String): T = inFlight.getOrPut(key) {
        async {
            source().also { inFlight.remove(key) }
        }
    }.await()
}

Deze Kotlin-klasse garandeert dat er voor elke sleutel slechts één coroutine wordt uitgevoerd. Alle parallelle aanroepen met dezelfde sleutel wachten op één Deferred. Na voltooiing wordt de sleutel verwijderd en wordt de volgende aanvraag normaal uitgevoerd.

Waarom is deduplicatie nodig in mobiele apps

Vermindering van de serverbelasting — de eerste en meest voor de hand liggende reden. Elke dubbele aanvraag verbruikt serverbronnen: CPU, geheugen, databaseverbindingen. Op schaal van miljoenen apparaten creëert zelfs 10–15% dubbele aanvragen aanzienlijke belasting die extra servers vereist.

Besparing van batterij en dataverkeer — elke HTTP-aanvraag op een mobiel apparaat verbruikt energie van de radiomodule. Volgens Google I/O (2025) kan één mislukte of dubbele aanvraag tot 15% van de energie van één netwerksessie verbruiken. Deduplicatie vermindert het aantal keren dat de radiomodule wordt ingeschakeld, waardoor de batterijduur van het apparaat wordt verlengd.

Voorkomen van gegevensconflicten — als twee dubbele aanvragen gegevens naar de lokale opslag schrijven, kunnen race conditions optreden: de tweede aanvraag kan het resultaat van de eerste overschrijven met verouderde gegevens. Deduplicatie garandeert dat het schrijven naar de lokale opslag eenmalig gebeurt, waardoor races worden geëlimineerd.

Verbetering van UX — de gebruiker ziet geen meerdere laadindicatoren voor dezelfde gegevens. De UI-status (loading / success / error) wordt beheerd door één bron van waarheid, niet door meerdere concurrerende aanvragen.

Memoization — cachen in het geheugen

Memoization (memorisatie) — is het cachen van het resultaat van een functie tijdens de uitvoering ervan. Als de functie al met dezelfde argumenten wordt uitgevoerd, start een nieuwe aanroep geen tweede proces, maar ontvangt het resultaat van de eerste. Dit is de eenvoudigste vorm van deduplicatie voor in-process scenario’s.

Typische implementatie in mobiele apps — HashMap van sleutels in Deferred of Promise. De sleutel is meestal de URL-string van de aanvraag of een concatenatie van parameters. De levensduur van de invoer — van de eerste aanvraag tot de voltooiing van het antwoord. Volgens Dropbox Engineering (2024) verminderde memorisatie in de Dropbox mobiele client het aantal dubbele API-aanvragen met 40%.

Flawed deduplication — een gevaarlijke fout: als u de sleutel niet verwijdert na een fout, zullen alle volgende aanvragen voor altijd dezelfde fout retourneren. Een correcte implementatie moet fouten en mislukkingen afhandelen, de cache wissen en opnieuw proberen toestaan.

class MemoizedLoaderT(
    private val loader: suspend () -> T
) {
    private var cachedResult: Result<T>? = null

    suspend fun get(): T = cachedResult ?.getOrThrow() ?: run {
        loader().let {
            Result.success(it)
        }.also { cachedResult = it }
    }.await()
}

MemoizedLoader gebruikt Result<T> voor correcte foutafhandeling: bij succes — cached het, bij fout — staat het opnieuw proberen toe. Deze aanpak garandeert dat een tijdelijke netwerkstoring volgende aanvragen niet blokkeert.

Request Merging — samenvoegen in batch

Request Merging (samenvoegen van aanvragen) — techniek waarbij meerdere verschillende aanvragen naar dezelfde bron worden verzameld in een groep en als één batch-aanvraag worden verzonden. In tegenstelling tot deduplicatie zijn de aanvragen niet identiek — ze verschillen in parameters, maar verwijzen naar dezelfde resource.

Typisch scenario: 5 schermen van de app vragen profielen van verschillende gebruikers op. In plaats van 5 afzonderlijke aanvragen naar /api/users/1, /api/users/2 enz., wacht het systeem 20 ms, verzamelt alle ID’s en stuurt één aanvraag /api/users?ids=1,2,3,4,5. Venstertime-out — cruciale parameter: een te lang venster verslechtert UX, een te kort venster laat niet toe voldoende aanvragen te verzamelen.

Volgens Netflix Engineering (2023) verminderde het samenvoegen van aanvragen in de GraphQL BFF (Backend for Frontend) aggregator het aantal HTTP-aanroepen tussen lagen met 65% en de gemiddelde responstijd met 120 ms door het elimineren van overbodige RTT’s. Asynchroon venster (debounce) — standaardimplementatie via coroutines of RxJava.

class BatchMergerT {
    private val pending = ConcurrentLinkedQueue<Pair<String, CompletableDeferred<T>>>()

    suspend fun get(id: String): T = suspendCoroutine { cont ->
        pending.add(Pair(id, cont))
        scheduleFlush()
    }
}

Deze mixin gebruikt suspendCoroutine om elke aanvraag op te schorten en een venster van 30 ms om de groep te verzamelen. Na het verstrijken van de timer worden alle verzamelde ID’s met één batch-aanvraag verzonden en ontvangt elke coroutine zijn eigen resultaat.

Serverdeduplicatie via DataLoader

DataLoader — is een bibliotheek (oorspronkelijk voor JavaScript/GraphQL) die batching en memorisatie aan de serverzijde implementeert. Het groepeert alle aanvragen naar dezelfde gegevensbron binnen één tick van de event loop en voert ze uit met één aanroep. DataLoader wordt veel gebruikt met GraphQL, maar kan in elke REST-applicatie worden toegepast.

Werkingsprincipe: alle aanroepen van loader.load(id) binnen één microtaak worden verzameld in een array van ID’s en doorgegeven aan de batch-functie. Na ontvangst van de resultaten krijgt elk ID zijn eigen array-element. Caching in DataLoader werkt slechts binnen één HTTP-aanvraag — bij de volgende aanvraag wordt de cache gereset, wat de actualiteit van gegevens waarborgt.

Volgens Meta Engineering (2024) elimineerde de implementatie van DataLoader in de GraphQL-laag van Facebook het N+1-probleem, waardoor het aantal databasequery’s daalde van 200 naar 10 per typische pagina. Batch scheduling — de belangrijkste innovatie van DataLoader — gebruikt process.nextTick (Node.js) of DispatchQueue.main (iOS) voor optimalisatie van groepering.

Welke deduplicatiestrategie kiezen

Memoization — optimaal voor één proces (mobiele app, microservice). Eenvoudig te implementeren en effectief voor identieke parallelle aanroepen. Nadeel — werkt niet tussen processen of apparaten.

Request Merging — geschikt voor de BFF-laag of een aggregerende service. Vereist ondersteuning voor batch-endpoints op de server. Beste keuze wanneer de frontend veel kleine aanvragen doet naar verschillende gegevens van hetzelfde type.

DataLoader — deduplicatiestandaard voor GraphQL-servers. Lost automatisch het N+1-probleem op en vereist geen handmatige configuratie van de cache. Aanbevolen voor elke server met een GraphQL-laag.

HTTP-cache met deduplicatie — op het niveau van OkHttp (Android) of URLSession (iOS) kan deduplicatie worden geconfigureerd via een Interceptor of delegate. OkHttp CacheInterceptor — een aangepaste onderschepper die controleert of een aanvraag met dezelfde URL al wordt uitgevoerd en ze samenvoegt. Deze methode werkt op een niveau onder de bedrijfslogica en dekt alle aanvragen van de app af zonder de featurecode te wijzigen.