Keeta Network recently demonstrated 11 million transactions per second on Google Spanner during a public stress test. That number matters less than the architectural choices behind it. When financial agents need to coordinate across geographies with strict ordering guarantees, the database layer becomes the bottleneck. Keeta's case study exposes the plumbing required to run blockchain-style workloads on distributed SQL infrastructure.
This is not about blockchain hype. This is about understanding how Spanner's TrueTime API, schema design, and transaction isolation levels enable high-throughput agent systems that need ACID guarantees without hotspotting.
Why Distributed SQL for Financial Agents
Traditional OLTP databases scale vertically. Sharding introduces coordination overhead. Financial agents that execute cross-border transactions, settlement workflows, or compliance checks need:
- External consistency: Transaction T1 committed before T2 globally, not just within a single node.
- Low-latency reads: Agents query account balances, compliance state, or asset ownership without blocking writes.
- Schema flexibility: Add new asset types, compliance rules, or identity fields without downtime.
Spanner provides these guarantees through TrueTime, a globally synchronized clock with bounded uncertainty. Every transaction gets a commit timestamp that respects causality across data centers. Agents can read stale data with bounded staleness or wait for strong consistency when ordering matters.
Keeta's Architecture: Schema and Isolation
Keeta runs a layer-1 blockchain on Spanner. Each transaction represents a state transition: asset transfer, compliance check, or cross-chain settlement. The schema design avoids common pitfalls:
Hot Key Avoidance
Blockchain workloads naturally create hotspots. Every block references the previous block. Every account balance update touches the same row. Keeta splits state across multiple tables:
- Account balances: Partitioned by account ID, not by block height.
- Transaction log: Append-only with timestamp-based sharding.
- Compliance state: Separate table with KYC/AML flags, indexed by identity hash.
This design lets agents query account state without blocking the transaction log. Writes to different accounts proceed in parallel. Spanner's lock-free snapshot isolation handles read-heavy workloads without contention.
Transaction Isolation Levels
Spanner offers three isolation levels:
| Isolation Level | Use Case | Trade-off |
|---|---|---|
| Serializable | Settlement finality, compliance audits | Highest latency, global locks |
| Snapshot | Agent balance queries, historical lookups | Stale reads possible, no write conflicts |
| Read-only | Analytics, reporting, observability | No consistency guarantees across queries |
Keeta uses serializable isolation for settlement transactions. Agents that check balances or validate compliance use snapshot reads with bounded staleness (10 seconds). This split reduces contention. Settlement agents wait for strong consistency. Query agents tolerate stale data.
TrueTime and Agent Coordination
TrueTime is Spanner's secret weapon. It provides a globally synchronized clock with bounded uncertainty (typically under 7ms). Every transaction gets a commit timestamp t where:
TT.now().earliest <= t <= TT.now().latest
Agents can coordinate without distributed locks. If Agent A commits a transaction at timestamp t1 and Agent B reads at t2 > t1, Agent B sees Agent A's write. No eventual consistency. No read-your-writes violations.
For financial workflows, this matters:
- Settlement agents can finalize cross-border transfers without waiting for manual reconciliation.
- Compliance agents can audit transaction history with strict ordering guarantees.
- Interoperability agents can bridge blockchain networks without trusting external oracles.
The cost is latency. Every write waits for TrueTime uncertainty to pass. Keeta's 11M TPS benchmark assumes agents tolerate this delay. Real-world deployments tune max_commit_delay based on geography and regulatory requirements.
Schema Design for Agent Workflows
Keeta's schema exposes three patterns useful for financial agent systems:
1. Event Sourcing with Append-Only Logs
Transactions are immutable events. Agents replay the log to reconstruct account state. Spanner's interleaved tables let you nest transaction details under account records:
CREATE TABLE Accounts (
account_id STRING(36) NOT NULL,
balance INT64 NOT NULL,
created_at TIMESTAMP NOT NULL OPTIONS (allow_commit_timestamp=true),
) PRIMARY KEY (account_id);
CREATE TABLE Transactions (
account_id STRING(36) NOT NULL,
tx_id STRING(36) NOT NULL,
amount INT64 NOT NULL,
timestamp TIMESTAMP NOT NULL OPTIONS (allow_commit_timestamp=true),
) PRIMARY KEY (account_id, tx_id),
INTERLEAVE IN PARENT Accounts ON DELETE CASCADE;
Agents query Accounts for current balance. Auditors query Transactions for history. Spanner co-locates related rows, reducing cross-node reads.
2. Compliance State as Separate Index
KYC/AML checks are read-heavy. Agents validate identity before executing transactions. Keeta stores compliance state in a separate table with secondary indexes:
CREATE TABLE ComplianceState (
identity_hash STRING(64) NOT NULL,
kyc_status STRING(16) NOT NULL,
aml_flags ARRAY<STRING(MAX)>,
last_updated TIMESTAMP NOT NULL OPTIONS (allow_commit_timestamp=true),
) PRIMARY KEY (identity_hash);
CREATE INDEX ComplianceByStatus ON ComplianceState(kyc_status);
Agents query by identity_hash without touching transaction tables. Compliance updates propagate asynchronously. Snapshot reads let agents validate identity while settlement proceeds.
3. Cross-Chain State with Foreign Keys
Keeta bridges multiple blockchains. Each chain has its own state table. Foreign keys enforce referential integrity:
CREATE TABLE ChainState (
chain_id STRING(36) NOT NULL,
block_height INT64 NOT NULL,
state_root STRING(64) NOT NULL,
) PRIMARY KEY (chain_id, block_height);
CREATE TABLE CrossChainTransfers (
transfer_id STRING(36) NOT NULL,
source_chain STRING(36) NOT NULL,
dest_chain STRING(36) NOT NULL,
amount INT64 NOT NULL,
FOREIGN KEY (source_chain) REFERENCES ChainState(chain_id),
FOREIGN KEY (dest_chain) REFERENCES ChainState(chain_id),
) PRIMARY KEY (transfer_id);
Agents validate cross-chain transfers by querying ChainState. Spanner enforces foreign key constraints across tables. No orphaned transfers. No double-spends.
Observability and Failure Modes
Spanner exposes metrics through Cloud Monitoring. Key signals for financial agents:
- Lock wait time: High values indicate schema hotspots or contention.
- Commit latency: Tracks TrueTime uncertainty and cross-region replication.
- Read staleness: Measures how far behind snapshot reads lag serializable writes.
Common failure modes:
| Failure Mode | Symptom | Mitigation |
|---|---|---|
| Hot key contention | Lock timeouts, high commit latency | Partition by account ID, use interleaved tables |
| TrueTime uncertainty spike | Increased write latency | Deploy across multiple regions, tune max_commit_delay
|
| Snapshot read lag | Agents see stale compliance state | Reduce staleness bound, use serializable reads for critical paths |
| Foreign key violations | Cross-chain transfers fail | Pre-validate chain state, use idempotent retries |
Keeta's 11M TPS benchmark assumes perfect conditions: no hotspots, low TrueTime uncertainty, and agents that tolerate stale reads. Production deployments need circuit breakers, retry logic, and fallback paths when Spanner's consistency guarantees conflict with latency requirements.
Deployment Shape
Keeta runs Spanner in multi-region configuration. Each region hosts:
- Spanner nodes: Handle reads and writes with local quorum.
- Agent workers: Execute settlement, compliance, and interoperability workflows.
- API gateways: Route requests to nearest Spanner region.
Agents communicate through gRPC. State changes propagate via Spanner's replication layer. No external message queue. No eventual consistency. Agents read from Spanner, execute business logic, and write back to Spanner.
This design simplifies observability. Every state transition is a database transaction. Audit logs are Spanner query results. Compliance reports are SQL queries.
The cost is vendor lock-in. Spanner's TrueTime API is proprietary. Migrating to Postgres, CockroachDB, or YugabyteDB requires rewriting coordination logic. Agents that depend on external consistency guarantees cannot tolerate eventual consistency.
When to Use This Pattern
Spanner-based financial agent infrastructure makes sense when:
- Strict ordering matters: Settlement finality, compliance audits, or cross-border transfers require external consistency.
- Geographic distribution is required: Agents operate across multiple regions with low-latency reads.
- Schema evolution is frequent: New asset types, compliance rules, or identity fields arrive regularly.
- Operational complexity is acceptable: You have the budget and expertise to run Spanner in production.
Avoid this pattern when:
- Latency is critical: TrueTime uncertainty adds 7-10ms to every write. High-frequency trading or real-time risk engines cannot tolerate this delay.
- Cost is a constraint: Spanner pricing scales with node count and storage. Small deployments pay for global infrastructure they do not use.
- Vendor lock-in is unacceptable: TrueTime is proprietary. Migrating to open-source alternatives requires rewriting coordination logic.
Technical Verdict
Keeta's 11M TPS benchmark demonstrates that distributed SQL can handle blockchain-style workloads without sacrificing ACID guarantees. The architecture exposes three lessons for financial agent systems:
- Schema design matters more than raw throughput: Avoid hot keys, use interleaved tables, and separate compliance state from transaction logs.
- TrueTime enables agent coordination without distributed locks: Agents can read stale data with bounded staleness or wait for strong consistency when ordering matters.
- Observability is built-in: Every state transition is a database transaction. Audit logs are SQL queries.
The trade-off is latency and vendor lock-in. Agents that need sub-millisecond writes or open-source portability should look elsewhere. For teams building cross-border settlement, compliance workflows, or asset tokenization platforms, Spanner's consistency guarantees justify the cost.
Top comments (0)