Our follow tables are also the first example we've seen of denormalization, which is the practice of storing the same data in more than one place. Denormalization is typically frowned upon in relational database schemas, although from a practical standpoint it's often a useful optimization even in that scenario. In non-relational databases, denormalization is often a critical tool in query-driven designs.
The downside of denormalization is exemplified by our preceding insert pattern: we have to make two INSERT statements to fully represent one fundamental fact. From a standpoint of performance, this is acceptable: Cassandra is optimized for efficient write operations, so we're happy to make verbose writes in order to allow efficient reads. This does, of course, add more complexity at the application level: the application is responsible for ensuring that any modification to the user_outbound_follows table is accompanied by an equivalent modification to the user_inbound_follows...