Herein, we consider a server-client architecture. Suppose we keep the details flexible, but there's more than one layer of servers supporting our hypothetical service. The general question is "When and how much do I validate client data?".
From other questions and answers I've read, the answer may be summarized as one of the following strategies (or a combination thereof).
- Validate all data as soon as it arrives from the client. Other servers trust each other.
- Validate all data on every server in the system. (this is not heavily favored)
- Validate all data rigorously when it reaches the database, and optionally elsewhere as required by the application.
- At all levels, validate exactly as much data as that particular server needs to do its job.
Number 3 seems particularly popular.
In the answers I've seen, however, there seems to be an implicit assumption of the classical RDBMS ("OldSql") centralized data storage. These are the MySQLs and Postgres's of the world. Taking cues from the CAP theorem, let's call these CP databases, as they tend to provide tools for consistency at the expense of some class of availability: usually, only a delegated master can write to a particular partition.
Recent alternatives to the classical RDBMS (specifically Voldemort, Riak, and Cassandra, which are modeled after the Dynamo storage system) are better classified as AP databases. These tools allow natural inconsistencies to appear upon data retrieval (e.g. multiple data values with vector clocks) in exchange for "always writeable" availability. Given that these data stores have rather unique properties, I pose the question:
Does the client data validation story change when we use AP datastores? How much of my client data should I validate before and after insertion to an AP database?