<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 29, 2014 at 4:15 PM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
It would, however, be bad to get a 404 for something that is otherwise<br>
present.. as that will result in an erroneous failure for the client.<br>
<div class=""><div class="h5"><br>
</div></div></blockquote><div><br></div><div>That almost never happens, but is possible if all the primaries are down*, a system than leans harder on the C a similar failure would be expected to treat a similar impossible question as a failure/error.</div><div><br></div><div>* It's actually if all the same nodes that answered the previous write are down; there's some trixies with error-limiting and stable handoffs that help with subsequent read-your-writes behavior that actually make it fairly difficult to write data that you can't then read back out unless you basically track where all of the writes go and then shut down *exactly* those nodes and make a read before replication beats you to it. Just shutting down all three primary locations will just write and then read from the same handoff locations, even if the primaries subsequently come back online (unless the primaries have an old copy - but it sounds like that's not going on in your application).</div><div><br></div><div>Again, all of this has to do with under failure edge cases. A healthy swift system; or even one that's only moderately degraded won't really see much of this.</div><div><br></div><div>Depending on the deployment latencies may be a concern if you're using this as a "cache" - have you looked at Swauth [1] already?</div><div><br></div><div>-Clay</div><div><br></div><div>1. <a href="https://github.com/gholt/swauth">https://github.com/gholt/swauth</a></div></div></div></div>