The biggest limitation I had was while writing to the database, the database would sometimes return an error for no apparent reason. I'd then be forced to catch these errors, and resubmit. But if you had lots of traffic and resubmit too quickly, Google App Engine would throw more errors back at you. This was all over a year ago, not sure how it is now, I would never go back to using it.
There is an expected failure rate on writes as Bigtable tablets are sometimes unavailable, for example, when they are being moved or split. The presence of more indexes increases the probability of hitting an unavailable tablet as an exception will be raised if a write fails for any of the indexes.
In those situations, your application will need to decide how to handle the exception. One option is to add a task to the task queue to retry the write at a later point in time. Another idea would be to respond with an error from the app and have the client retry. This tends to work with things like AJAX requests where there is client side logic which can handle an error message from the server.
Weird. If the entire keyspace isn't affected, seems like you might want to use another region as the 'task queue'. That is, if you get an error where you want to insert something, add a prefix that lands it on another tablet. Occasionally scan those failover regions for values that can be moved back to their real keys, later.
you need to trap DeadlineExceededError for long-running queries, CapabilityDisabledError (from google.appengine.runtime.apiproxy_errors) for when the datastore is in maintenance mode and other misc errors. If it is a deadline error, you can re-submit it (but prob advisable to only re-sub once), on CapabilityDisabledError, return a server error page or load from memcache
From http://code.google.com/appengine/articles/life_of_write.html
There is an expected failure rate on writes as Bigtable tablets are sometimes unavailable, for example, when they are being moved or split. The presence of more indexes increases the probability of hitting an unavailable tablet as an exception will be raised if a write fails for any of the indexes. In those situations, your application will need to decide how to handle the exception. One option is to add a task to the task queue to retry the write at a later point in time. Another idea would be to respond with an error from the app and have the client retry. This tends to work with things like AJAX requests where there is client side logic which can handle an error message from the server.