Hoe plan je als techlead voor tien keer zoveel gebruikers?

Question

IT Interview Practice · Accepted Answer

Als tech lead zou ik **“tien keer zoveel gebruikers” eerst vertalen naar verwacht gebruik, servicedoelen en een uitvoerbaar teamplan**. Het aantal geregistreerde accounts vertelt niet hoeveel verzoeken op het drukste moment binnenkomen.

Stel dat het bedrijf een campagne voor een bestelplatform plant. De vraag is of klanten tijdens die campagne nog kunnen rondkijken, kopen en bevestiging ontvangen, binnen de beschikbare tijd en het budget.

## 1. Vertaal groei naar belasting

Vraag product wanneer gebruikers komen en wat ze gaan doen. Een geleidelijke stijging over een jaar verschilt van een campagne die iedereen tegelijk online brengt.

Bijvoorbeeld: 100.000 geregistreerde accounts waarvan 1% tegelijk actief is, betekent 1.000 gelijktijdige gebruikers. Bij 5% zijn het er 5.000. Dit zijn voorbeeldaannames, geen standaardverhoudingen. Verzoekfrequentie en werk per verzoek moeten nog worden geschat.

Breng de campagnebelasting in kaart:

- Browse- en zoekverzoeken, inclusief populaire producten.
- Bestel- en betalingsschrijfacties tijdens pieken.
- Groei van opslag en bewaarde historie.
- Achtergrondwerk zoals meldingen en rapporten.

Dit geeft testbare belastingen in plaats van een vage opdracht om het serveraantal met tien te vermenigvuldigen.

## 2. Spreek af wat goed moet blijven

Definieer acceptabele responstijd, foutpercentage en voltooiing voor kritieke klantreizen. Leg waar relevant ook actualiteit en herstelverwachtingen vast. Een vertraagd rapport kan acceptabel zijn, een mislukte checkout niet.

```text
[Campaign assumptions] -> [Expected workload] -> [Service targets]
                                                   |
                                            [Acceptance tests]
```

De doelen verbinden technisch werk aan klantresultaten. Ze bepalen wanneer een verbetering voldoende is en welke achteruitgang onder druk kan worden verdragen.

## 3. Meet de huidige grens voordat je wijzigingen kiest

Gebruik productieobservaties en representatieve belastingtests. Bekijk trage queries, databaseverbindingen, CPU, geheugen, wachttijd in queues en externe quota. Neem ongelijk verkeer naar populaire artikelen mee, niet alleen willekeurige verzoeken.

Als databaseverbindingen de grens vormen, kunnen extra applicatienodes meer concurrentie veroorzaken. Als het quotum van de betaalprovider de grens vormt, verhoogt een snellere applicatie dat quotum niet.

Test koude caches en het verlies van een instantie naast normaal gebruik. We hebben herstelcapaciteit tijdens de campagne nodig, niet alleen genoeg capaciteit voor een ideale testrun.

## 4. Zet bevindingen om in werk met eigenaarschap

| Bevinding | Mogelijke actie | Vereist bewijs |
| --- | --- | --- |
| Herhaalde dure leesacties | Verbeter de query of cache geschikte resultaten | Minder databasewerk bij acceptabele actualiteit. |
| Achtergrondtaken concurreren met aankopen | Begrens of isoleer hun capaciteit | Checkout blijft gezond onder achtergrondbelasting. |
| Een afhankelijkheidsquotum is te laag | Regel verhoging of beheer toelating | Bevestigd quotum en getest gedrag bij de grens. |
| Capaciteit blijft onvoldoende na kleine verbeteringen | Beoordeel opschalen of een grotere ontwerpwijziging | Gemeten voordeel, migratieplan en kosten. |

Geef iedere actie een eigenaar, budget, afhankelijkheden, einddatum en acceptatietest. Neem deployment, operationele training en on-callvoorbereiding mee, niet alleen implementatie.

Prioriteer op klantimpact en uitvoeringsrisico. Een grote herbouw of shardingproject vraagt een aantoonbare reden en voldoende tijd voor migratie en verificatie.

## 5. Oefen de campagne en verhoog verkeer geleidelijk

Lever wijzigingen in beheersbare stappen en test de verwachte klantreizen samen. Bepaal wanneer verkeer wordt uitgebreid, uitbreiding pauzeert of wordt teruggedraaid. Wijzigingen in dataformaat kunnen voorwaarts herstel vereisen in plaats van een eenvoudige rollback.

Bereid gecontroleerde degradatie voor: stel optionele exports uit, begrens achtergrondwerk of weiger overtollige verzoeken terwijl kritieke functies behouden blijven. Controleer dat dit werkelijk belasting vermindert en klanten een duidelijke uitkomst krijgen.

Als het doel niet binnen datum of budget past, bied product concrete opties: gefaseerde instroom, een dure functie beperken of het gemeten knelpunt financieren. Leg klantimpact en onzekerheid van elke optie uit.

**Onthoud:** groeiaannames → servicedoelen → gemeten grenzen → roadmap met eigenaars → geoefende uitrol. De tech lead levert een capaciteitsplan met mensen, geld en herstel.

Bevinding	Mogelijke actie	Vereist bewijs
Herhaalde dure leesacties	Verbeter de query of cache geschikte resultaten	Minder databasewerk bij acceptabele actualiteit.
Achtergrondtaken concurreren met aankopen	Begrens of isoleer hun capaciteit	Checkout blijft gezond onder achtergrondbelasting.
Een afhankelijkheidsquotum is te laag	Regel verhoging of beheer toelating	Bevestigd quotum en getest gedrag bij de grens.
Capaciteit blijft onvoldoende na kleine verbeteringen	Beoordeel opschalen of een grotere ontwerpwijziging	Gemeten voordeel, migratieplan en kosten.

1. Vertaal groei naar belasting

2. Spreek af wat goed moet blijven

3. Meet de huidige grens voordat je wijzigingen kiest

4. Zet bevindingen om in werk met eigenaarschap

5. Oefen de campagne en verhoog verkeer geleidelijk

Gerelateerde vragen