---
title: "Using Triggers On Schemaless, Uber Engineering's Datastore Using MySQL"
description: "Schemaless triggers provides a scalable, fault-tolerant, and lossless way to listen for changes in Schemaless, Uber Engineering’s datastore using MySQL, and drives workflows including trip billing, analytics-warehouse ingestion, and cross-datacenter replication. Schemaless stores immutable cells and all their versions, allowing each shard to function as a partitioned change log with monotonically increasing added IDs while retaining random-access APIs. The framework tails shards through get_cells_for_shard, assigns them to worker processes under a leader, persists offsets in shared storage, and invokes column-specific callbacks such as bill_rider; handlers must be idempotent because retries can occur. Failed workers’ shards are reassigned, repeatedly failing cells can move to a separate queue, processing continues during leader or shared-storage outages although redistribution pauses, and replicas insulate triggers from database-node failures."
---

# Using Triggers On Schemaless, Uber Engineering's Datastore Using MySQL

[Uber](https://yomu.fyi/company/uber) · Jul 31, 2026

**Type:** Explainer

## Summary

Schemaless triggers provides a scalable, fault-tolerant, and lossless way to listen for changes in Schemaless, Uber Engineering’s datastore using MySQL, and drives workflows including trip billing, analytics-warehouse ingestion, and cross-datacenter replication. Schemaless stores immutable cells and all their versions, allowing each shard to function as a partitioned change log with monotonically increasing added IDs while retaining random-access APIs. The framework tails shards through get\_cells\_for\_shard, assigns them to worker processes under a leader, persists offsets in shared storage, and invokes column-specific callbacks such as bill\_rider; handlers must be idempotent because retries can occur. Failed workers’ shards are reassigned, repeatedly failing cells can move to a separate queue, processing continues during leader or shared-storage outages although redistribution pauses, and replicas insulate triggers from database-node failures.

## Context

Trip processing requires reacting to Schemaless changes, from a completed trip and rider billing to warehouse ingestion. The framework is intended to decouple producers and consumers while handling scaling, retries, worker failures, and other operational failures.

## Approach / What changed

Schemaless triggers tails Schemaless’s partitioned, log-style API, assigns shards to worker processes, invokes callbacks for new cells, and persists per-shard offsets in shared storage. A leader coordinates shard assignment and worker membership, while retries, failure queues, reassignment, and replica reads support continued processing.

## Takeaways

- Schemaless retains every cell version and assigns cells monotonically increasing added IDs within each shard, supporting both random-access retrieval and log-style tailing.
- Trigger callbacks are guaranteed to run at least once for each cell, so handlers must be idempotent to safely handle retries caused by application or transient external errors.
- Workers process assigned shards in write order, and a leader can reassign shards after worker failure; repeated failures may be isolated in a separate queue to avoid stalling a shard.

**Tags:** [Data Pipelines](https://yomu.fyi/topic/data-pipelines), [Distributed Systems](https://yomu.fyi/topic/distributed-systems), [MySQL](https://yomu.fyi/topic/mysql), [Reliability](https://yomu.fyi/topic/reliability)

- Source: [Uber](https://www.uber.com/us/en/blog/schemaless-part-three-datastore-triggers)
- Source URL: https://www.uber.com/us/en/blog/schemaless-part-three-datastore-triggers
- Ingested by Yomu: 2026-09-10T15:19:09.787Z

[Read original post](https://www.uber.com/us/en/blog/schemaless-part-three-datastore-triggers)