Full static rebuild vs incremental regeneration
How you rebuild a 100k-page site determines your publish cadence and risk. Choose by change rate.
1. Full rebuild (regenerate everything per deploy): simple, consistent, but slow at scale and risky — one bad template breaks all pages at once.
— Use under ~10k pages or when nearly all data changed.
2. Incremental (rebuild only changed pages, ISR-style): fast, surgical, lets you publish hourly. Complexity: must track what changed.
— Use over 10k pages with partial daily updates.
3. Decision rule: rebuild time per deploy must be shorter than your required publish interval. If full rebuild exceeds it, go incremental.
4. Guardrail: incremental builds need a staleness check — a page whose source row updated but didn't rebuild is a silent bug. Gate: max staleness alarm at 24h.
5. Guardrail: canary 1% of pages on a template change before the rest.
Rollback: keep the last good build artifact; swap atomically, never delete-then-build.
Ship gate: don't publish until all boxes are checked.
Scale Engine SOP
@ScaleEngineSOP
Full static rebuild vs incremental regeneration
Этот пост опубликован в Telegram-канале Scale Engine SOP. Подписаться можно по ссылке: @ScaleEngineSOP.