ContextSync at Enterprise Scale

From Hackathon to Production

The reference implementation uses SQLite and a local filesystem — the right choices for proving a protocol works in eleven hours. But ContextSync is designed as a protocol, not a product. The same API surface, the same URI scheme, the same permission tuples, and the same provenance records map cleanly onto production cloud infrastructure.

This page shows how.

Architecture Comparison

Google Cloud Architecture

                            Judges / Agents / Humans
                                     |
                              Cloud CDN + LB
                                     |
                            +--------v---------+
                            |  Cloud Run       |
                            |  ContextSync API |
                            |  (auto-scaling)  |
                            +--------+---------+
                                     |
          +-----------+--------------+--------------+-------------+
          |           |              |              |             |
    +-----v----+ +---v------+ +----v-----+ +------v-----+ +----v--------+
    | Cloud    | | Cloud    | | Pub/Sub  | | Verified   | | BigQuery    |
    | Storage  | | Spanner  | |          | | Access     | | (provenance)|
    | (blobs)  | | (version | | (change  | | (IAM +     | |             |
    |          | |  graph)  | |  events) | |  OPA)      | |             |
    +----------+ +----------+ +----+-----+ +------------+ +-------------+
                                   |
                            +------v-------+
                            | Eventarc     |
                            | (route to    |
                            |  subscribers)|
                            +--------------+

Why Cloud Run: ContextSync is a stateless HTTP + SSE server. Cloud Run scales to zero when idle, scales to hundreds of instances under load, and requires no cluster management. The SSE hub moves from in-memory to Pub/Sub, so each instance subscribes independently.

Why Cloud Spanner: the version graph needs strong consistency (version numbers must be monotonically increasing, no gaps). Spanner provides this globally. For smaller deployments, Firestore is simpler and cheaper.

Why BigQuery for provenance: provenance is append-only, rarely queried in real time, and grows without bound. BigQuery handles petabyte-scale append workloads at low cost with full SQL query capability for compliance audits.

Amazon Web Services Architecture

                            Judges / Agents / Humans
                                     |
                              CloudFront + ALB
                                     |
                            +--------v---------+
                            |  ECS Fargate     |
                            |  ContextSync API |
                            |  (auto-scaling)  |
                            +--------+---------+
                                     |
          +-----------+--------------+--------------+-------------+
          |           |              |              |             |
    +-----v----+ +---v------+ +----v-----+ +------v-----+ +----v--------+
    | S3       | | Aurora   | | SNS/SQS  | | Verified   | | Timestream  |
    | (blobs)  | | Postgres | |          | | Permissions| | or S3 +     |
    |          | | (version | | (change  | | (Cedar)    | | Athena      |
    |          | |  graph)  | |  events) | |            | | (provenance)|
    +----------+ +----------+ +----+-----+ +------------+ +-------------+
                                   |
                            +------v-------+
                            | EventBridge  |
                            | (routing     |
                            |  rules)      |
                            +--------------+

Why ECS Fargate: same rationale as Cloud Run — stateless compute, auto-scaling, no infrastructure to manage. Fargate tasks map 1:1 to ContextSync server instances.

Why Aurora PostgreSQL: the version graph is a relational workload (foreign keys, monotonic sequences, joins for history queries). Aurora gives Multi-AZ durability with PostgreSQL compatibility. For global deployments, DynamoDB Global Tables trade strong consistency for multi-region availability.

Why Amazon Verified Permissions: Cedar is a purpose-built policy language for fine-grained authorization. ContextSync's permission tuples (actor, pattern, operations) map directly onto Cedar policies, with evaluation offloaded to a managed service instead of in-process middleware.

Federation: Multi-Region, Multi-Cloud

The hardest enterprise question is not "which cloud?" but "how do two ContextSync servers stay in sync across regions or providers?"

The protocol's change-event schema is the federation primitive. Each server publishes change events to its own message bus (Pub/Sub or SNS). A federation bridge subscribes to the remote server's change feed and replays events locally:

  Region: EU (GCP)                          Region: US (AWS)
  +------------------+                      +------------------+
  | ContextSync      |   change events      | ContextSync      |
  | Server (EU)      | <------------------> | Server (US)      |
  +--------+---------+   (Pub/Sub <-> SNS   +--------+---------+
           |               bridge)                    |
     +-----+-----+                             +-----+-----+
     | Spanner   |                             | Aurora    |
     | (EU data) |                             | (US data) |
     +-----------+                             +-----------+

Conflict resolution: in v0.1, ContextSync detects but does not auto-resolve conflicts. In a federated deployment, the same artifact could be written simultaneously in two regions. The federation bridge detects the version fork (two versions with the same parent) and flags it for human review. Automatic merge strategies (last-writer-wins, region-priority, or domain-specific rules) are a v0.3 feature, but the detection mechanism works today because version numbers are monotonic per-artifact.

Data residency: federation does not require full replication. An EU server can subscribe to only the change metadata (URI, version, author, summary) from the US server without replicating the artifact payload. This satisfies data residency constraints: the EU server knows what changed in the US and can request the payload on demand if permissions allow.

What Changes, What Stays the Same

The protocol surface is invariant. The infrastructure underneath is a deployment decision. That is the point of building a protocol instead of a product.