The worse case is when, for a GET request, a key results in a false positive in the write-friendly store, false positives in all the intermediary stores, and a successful match or false positive in the memory-efficient store.

Here is how this happens:

The GET request first searches in the write-friendly store. A false positive occurs when the computed hash of the partial key matches the tag in the bucket, and the returned key from storage does not match the key from the GET request. We have incurred one storage seek.
Now the GET request searches in the intermediary stores from the latest to the oldest. False positive occurs in the intermediary store as in the write-friendly store. False positives in all the intermediary stores have made us incur $I$ storage seeks.
Now in the memory-efficient store, our compact representation of a prefix tree will always provide us with a leaf node with an index to look for our key. We will incur a storage seek regardless of whether it was a false positive.

So in total, total storage seeks are $2 + I$ .

Prologue

File Systems

Google File System (GFS)

Google Colossus File System

Facebook's Tectonic File System

Databases

Google Bigtable

Google Megastore

Google Spanner

Key-value Stores

Many-core Key-value Store

Scaling Memcache

SILT

Amazon DynamoDB

Concurrency Management

Two-phase Locking (2PL)

Google Chubby Locking Service

ZooKeeper

Big Data Processing: Batch to Stream Processing

MapReduce

Spark

Kafka

Consensus

Understanding Consensus: Two Generals, FLP, & Byzantine Generals

Two-phase Commit

State Machine Replication

Paxos

Raft

Epilogue

Quiz on SILT

Question 1

1 of 5