When and how much should we validate input when working with (C)AP storage?

Question

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).

1. Validate all data as soon as it arrives from the client. Other servers trust each other.
2. Validate all data on every server in the system. (this is not heavily favored)
3. Validate all data rigorously when it reaches the database, and optionally elsewhere as required by the application.
4. 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?

Answer 1

In any system (CP or AP) I would go for option 1.

There are many advantages to validating as early as possible.

• You have the whole transaction, you know all about it and who initiated it. You can provide meaningful error messages.
• You can check for a lot more.
• You should be "read only" until the entire request is validated. No complex roll backs to worry about!

Answer 2

This issue revolves around being able to trust a calling layer. Each intra layer communication can be seen as a client-server system. At one point you will end up having the bottom layer to make a decission wheter or not the incoming data is valid. So therefore the paradigm stands, don't trust anything the client tells you!

The validation that you execute though varies per layer of the application, specifically per layer responsibility. If you talk about a persistence layer, it should at minimum check wheter it's able to properly store and retrieve the data handed down from the client. If something invalid is found, only the caller should be informed. The caller itself is then responsible for further notification. That also means you do not check business rules because in essence that is not the persistence layers responsibility.