Manhattan

Manhattan is the database Twitter built for itself and runs as an internal service: engineers ask for storage size and queries per second in a self-service portal and get a dataset on a shared cluster in seconds, without waiting for hardware or a schema. A dataset is a group of keys for one use case, like a table. Keys have two parts, a partition key that decides where a record lives and sorted local keys under it, and since many datasets share a cluster, every stored key also carries the dataset’s ID. It is described as the default store at Twitter for persistent real-time serving, holding core data such as Tweets, users and direct messages.

Stateless coordinators accept requests and route them to storage nodes; each key belongs to one shard, and a storage node holds hundreds or thousands of shards. By default the system is eventually consistent in the style of Amazon’s Dynamo: a write waits only for its local zone, other zones and datacenters receive it asynchronously, and replicas converge through continuous replica reconciliation, read repair and hinted handoff. Rate limiting at sub-second granularity and quotas stop one tenant from hurting the others. ZooKeeper holds the cluster topology but is not on the read or write path.

Datasets that need more can opt into strong consistency. Then every operation on a key goes through a per-shard replicated log in DistributedLog, Twitter’s log service, with one elected writer per log; storage nodes apply each log in order, so all replicas reach the same state. That gives atomic check-and-set, increments and strongly consistent reads per partition key, within one datacenter (tens of milliseconds at p99) or across all of them (hundreds), but no transactions across keys. Storage engines are pluggable: the original ones were an LSM engine, a B-tree engine built as a MySQL plugin over InnoDB, and a read-only format for data imported from Hadoop; from 2018 Twitter moved its main clusters to RocksDB.