Building on Tape - Projection Tables and Tape-First Architecture

[Jason]

This is a fairly technical and advanced post.

I have been meaning to make some videos showing this approach in practice, but as that has not happened yet, I thought I would write up some of the principles behind how we build Tape-first systems.

Tape as the Operational Source of Truth

In my view, Tape is still incredibly difficult to beat as an operational platform.

It excels at:

• Entering and manipulating operational data
• Automating workflows
• Receiving and distributing information
• Scaling with both technical and non-technical users
• Rapidly adapting to changing business processes

The key principle behind everything we build is this:

Tape remains the operational source of truth.

All updates, operational actions and workflow logic happen in Tape first.

However, operational systems and high-performance public-facing systems are not always the same thing.

Sometimes you need:

• Public web pages
• Client portals
• Role-based dashboards
• Search-heavy interfaces
• Real-time map displays
• Large-scale read access
• Complex aggregated views

These are all things Tape can power, but they are not necessarily things that should rely entirely on live API reads for every request.

Examples of Systems We Have Built on Tape

Some examples from recent projects:

• Client portals
• Client onboarding systems
• Association management system (clubs, members, roles, uploads, CMS-driven website)
• Location plotting systems
• Email systems linked to CRM records
• Link shorteners
• Secure document portals
• Training platforms
• Secure ordering systems with client-specific product access
• Holiday approval systems
• Expense approval systems

What these systems all have in common:

External web front ends
Tape as the source of truth
Dynamic behaviour driven by Tape data

Our own internal platform, Aurora Gate, is heavily built around this principle.

For example, notes relating to projects or clients are editable directly inside Tape, but are also viewable and editable inside Aurora Gate. This allows them to be securely shared with external systems and users while still keeping Tape as the operational source of truth.

Editing a note inside Aurora Gate

The same note inside Tape

A bonus is Mobile

In this example, I can edit a note in Tape, mark it as public and immediately generate a share link. The public version updates almost instantly.

The Problem With Live API Reads

Tape has a very capable API and it is fast.

However, imagine a visitor opening a public note page.

If every request queried Tape directly, the application would need to:

1. Query Tape
2. Locate the record
3. Validate that the record is public
4. Transform the content for display
5. Render the final page

That may sound perfectly reasonable, but this process happens on every request.

Now multiply that across:

• Multiple records
• Related applications
• Complex views
• External systems
• Large numbers of users

Performance quickly becomes a problem.

When we are aiming for highly optimised web experiences, even relatively small delays become noticeable.

100% Lighthouse score

And that is for a relatively simple page.

What happens when you start building more complex interfaces pulling data from multiple applications and systems?

A complex Page

In Aurora Gate, pages like this still achieve extremely high performance scores.

That simply would not be possible if every piece of data required live API calls back to Tape during page rendering.

So How Do We Solve This?

Simply put:

We cheat.

We use Projection Tables.

A Projection Table is effectively a read-optimised copy of selected Tape data that stays synchronised in near real time.

If you come from a traditional software architecture background, these are essentially read models or projection views.

Instead of querying Tape directly for every page request, our applications query the Projection Tables instead.

This gives us:

• Extremely fast reads
• Predictable performance
• Reduced API load
• Better scalability
• Easier aggregation across systems

The important point is this:

Tape is still the source of truth.

Projection Tables are only optimised read models.

All writes still happen in Tape.

Delta Node

As we built more systems, we realised we were repeatedly building similar synchronisation logic and duplicating API calls.

So we built a system to automate Projection Table provisioning and synchronisation.

We call it Delta Node.

Delta Node allows us to:

• Create Projection Tables automatically
• Keep them synchronised with Tape
• Reuse the same projections across multiple systems
• Minimise API usage
• Provision infrastructure quickly

For example, Aurora Gate and our client portal both use the same client Projection Tables while presenting the data differently.

How Delta Node Works

Inside Delta Node you can:

1. Select a Tape organisation
2. Select a workspace
3. Select an application
4. Choose which fields should be included in the Projection Table

All of this metadata is pulled live from Tape via the API.

Application selection

Field selection

Once configured, pressing Provision Projection will:

1. Create a new database table
2. Create synchronisation endpoints
3. Configure Tape webhooks
4. Optionally backfill existing records
5. Keep the Projection Table synchronised in real time

Webhook provisioning

Real-time synchronisation

Backfills and Scaling

Backfills are one of the areas where systems can go wrong very quickly.

Synchronising a handful of records is easy.

Synchronising thousands of records while staying within API limits is a very different problem.

Because of this, Delta Node offloads backfills into separate background workflows which process records safely and incrementally.

This keeps the system responsive while avoiding spikes in API usage.

A Small Bonus

Sharp-eyed readers may notice an additional webhook:

App Updated

The Tape team quietly added this at some point. Last time I checked it was not yet documented in the API documentation, but it is actually extremely useful when building synchronisation systems.

Final Thoughts

Projection Tables have fundamentally changed how we build on Tape.

They allow us to:

• Keep Tape as the operational source of truth
• Deliver extremely fast web experiences
• Scale to more complex systems
• Reduce API overhead
• Share consistent data across multiple applications

The important mindset shift is this:

Tape is the operational layer.

Projection Tables are the delivery layer.

Or more simply:

Write to Tape. Read from Projection Tables.

[tomaz]

@Jason
This is a fantastic write-up — the concept of Projection Tables as a delivery layer while keeping Tape as the operational source of truth really clicks, and Delta Node sounds like an elegant solution to a problem many teams just patch over. Could you share more about the technical architecture behind Delta Node? For example, is it hosted locally or in the cloud, and what does the backend and frontend stack look like?

[RobertForster]

@Jason
Absolutely incredible to see what you can build with Tape. Really impressive work.

[Jason]

Okay @tomaz , probably more than you asked for

Delta Node is entirely cloud hosted and heavily built around the Cloudflare ecosystem.

Delta Node itself is a Cloudflare Worker application built with Astro SSR, using Preact on the frontend and UnoCSS for styling. Projection tables are stored in D1, and larger projection backfill operations are handed off to Cloudflare Workflows so they can run safely in the background without risking API spikes or timeout issues.

Aurora Gate is architecturally very similar, although it also makes fairly heavy use of Durable Objects, Queues and KV depending on the workload. It also has a dedicated scheduler worker responsible for CRON jobs and scheduled processing.

You may also have noticed some bookmark-related items on the project page. Those come from a separate ingestion system where a submitted URL is retrieved, processed and pushed into a Queue. AI then generates summaries, analyses the content and attempts to match it against projects or topics based on similarity scoring.

There is also a central notifications service which acts as a routing hub for all system notifications. External systems, including Tape, can push notifications into it and routing rules determine where and how those notifications are delivered.

Aurora Gate additionally pulls together data from multiple systems including:

• Our accounts system. Invoices themselves are stored in Tape.
• Observability and logging systems.
• Email and calendar data pulled in via Fastmail integrations, with relevant business context surfaced through Aurora Gate and Tape-backed Notes and Logs workflows.
• News searches and external intelligence feeds.
• Toggl time tracking data. Time entries are stored in Tape and linked back to organisations and projects.
• Linear for issue tracking

Meeting data including meeting notes are written directly into Tape and then surfaced through Aurora Gate via the projection layer.

The system then aggregates everything together into daily briefings, operational summaries and project intelligence views.

The overall approach is really about treating Tape as the operational core, while surrounding it with highly specialised services optimised for delivery, processing and aggregation.

Over time we have also built a growing collection of internal packages for:

• Tape interactions
• Postmark integrations
• Astro templates
• Shared UI components
• Authentication helpers
• Common service patterns

That makes it significantly easier to spin up new systems and services which are built on Tape.

One other important aspect is authentication. For internal systems we primarily use Cloudflare Zero Trust, and where required we can also use Cloudflare Tunnel to securely connect internal or self-hosted services into the wider platform.

One last architectural detail worth mentioning is how we handle high-frequency editing workflows such as note editing inside Aurora Gate.

For most operational data we follow the rule of:

Write to Tape, read from projections.

However, that model becomes inefficient for highly interactive editing experiences such as autosaving note content. Writing every keystroke or rapid edit cycle directly back to Tape would generate unnecessary API traffic and create a noticeably worse user experience.

This is one of the areas where Durable Objects become extremely useful.

Instead of immediately persisting every edit back to Tape, changes are first written into a Durable Object which acts as a low-latency state and coordination layer for that document or editing session. The Durable Object can then intelligently batch, debounce and consolidate updates before synchronising the final state back into Tape.

This allows the frontend editing experience to remain extremely responsive while still preserving the core architectural principle that Tape remains the long-term operational source of truth.