The Database

We store one record per link:

status records whether the link is active, blocked, or turned off. Drive also adds a documentId field, and O’Reilly adds a bookId field.

Relational or document

When we designed Shopend, a product’s attributes differed from merchant to merchant, and a cart held a list of items. A document database fit that data. A link has neither. It is one flat record.

The lookups other than by code use an index: Drive’s lookup by documentId, and O’Reilly’s lookup by bookId. Relational and document databases both support these indexes.

So either one works for all three variants. A document database has no advantage here. Relational is my default, so I choose relational for all three.

Key-value databases

Following a link is by far the most frequent operation. It reads one link by its code. This is a lookup by key. Some databases are built for lookups by key.

In the caching chapter, we stored HopPress’s cache entries in a key-value store, such as Redis. A key-value database stores each value under a key, and reads and writes a value by its key. Redis can also run as a database. It saves its data to disk and keeps replicas.

If following a link is a lookup by key, should we store the links in a key-value database?

One advantage is that most key-value databases have sharding built in. The database divides the data across shards and routes each lookup to the right one, so we do not build a shard router ourselves. t.co and Drive store terabytes of links a year, so they need sharding.

The disadvantage is that a key-value database finds a value only by its key. It cannot query by anything inside the value. But each variant also has an operation that finds links by something other than the code:

• Drive turns a document’s link off and back on. The lookup is by document.
• X blocks the links to a harmful site. The lookup is by site.
• O’Reilly lists a book’s links. The lookup is by book.

Each of these lookups has a workaround. Drive could store the code with the document’s own data. X could check every redirect against a list of blocked sites. Or we could keep a second key-value mapping from document to code. In each workaround, we build the lookup ourselves and keep it up to date. A relational or document database would give us that lookup through an index.

So all three kinds of database work for the links. Which one to use is a judgment call. I stay with relational for all three variants.