I know nothing about twitter's architecture but it could be: - at-rest encryption of the datastores with the content encryption key protected by a HSM. A KMS (

I know nothing about twitter's architecture but it could be: - at-rest encryption of the datastores with the content encryption key protected by a HSM. A KMS (key management system) would be the interface to retrieve the key, with access control enabled. An even better solution would be to have the HSM cipher/decipher the data directly, thus the encryption key would never leave the HSM (or the encryption key is also ciphered by the HSM). But performance-wise it is not realistic. - in-transit encryption from the client to the datastore. No end-to-end encryption more likely thus allowing admins who have access to encryption termination hosts (reverse proxy, twitter backend app, datastore,etc) to read (and maybe alter) the data by doing memory dumps - access control for datastore operations: allowing only the twitter backend and some privileged users to read/write in the datastores, etc. Doing end-to-end encryption from the client to the datastore with a key per client is possible but it would make the solution very complex to operate and not performant.