Tigris is a globally distributed object storage system where objects are stored all over the world. The system needs to have asynchronous tasks to keep objects cached, redundantly stored, and moved around in response to changes in access patterns.
To solve this, we built an asynchronous task system on top of FoundationDB, just like our metadata. This simplifies our architecture by letting us enqueue tasks in the same transaction as we insert data, providing us atomicity with all or nothing semantics. This wouldn’t be as easy if we used an external system because we’d need distributed coordination between our database and our message queue. We also wanted to take advantage of our existing FoundationDB clusters and expertise to avoid having to make things too complicated for our SREs. Today I’ll cover how FoundationDB makes this easy, the other advantages it’s given us, and some lessons we learned in the process.
Himank is the CTO and co-founder of Tigris Data. His primary focus is building the distributed systems that make Tigris’ object storage system scale along with its users. Prior to Tigris he worked at Uber on the distributed databases team that stored petabytes of data and enabled millions of queries per second across multiple clouds. Himank holds a master’s degree with a specialization in distributed systems.
