Skip to content

Add ADR to precompute API cache for resilience#677

Draft
edavey wants to merge 1 commit into
mainfrom
add-adr-14-to-precompute-api-cache-for-resilience
Draft

Add ADR to precompute API cache for resilience#677
edavey wants to merge 1 commit into
mainfrom
add-adr-14-to-precompute-api-cache-for-resilience

Conversation

@edavey
Copy link
Copy Markdown
Collaborator

@edavey edavey commented May 21, 2026

DRAFT: Please let us know what you think


ADR to precompute API cache for resilience

ADR 13: Add an API for Content Block Manager establishes that Content Block Manager (CBM) will expose a
rendering API (POST /api/blocks/render) which Publishing API and other applications will call instead of rendering
content blocks locally via the content_block_tools gem.

This will introduce a network dependency where none exists today.

See ADR for details.

### 3. Rely on Sidekiq retry for resilience (initially)

If the render API is unavailable or times out, `DownstreamLiveJob` in Publishing API will fail and retry via
Sidekiq's built-in exponential backoff (25 retries over ~21 days). This provides resilience without application-level retry logic.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This proposal seems to depend heavily on processing of documents in Publishing API being asynchronous. However we are moving away from this with GraphQL, where links are expanded and content blocks are embedded at the point of a user requesting the page.

Have you taken this into consideration, as it'll mean we'll need to additionally make a request to Content Block Manager when rendering content to the public?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants