7 ms·

> failure to receive back any reply within the stipulated deadline If you get this error back, the client doesn't know if the server actually processed it or n

> failure to receive back any reply within the stipulated deadline If you get this error back, the client doesn't know if the server actually processed it or not, so knowing where the client failed isn't actually useful for knowing the state of the request and what needs to happen next. To handle something like this, you need a resilient design around client-server communications (e.g. assuming retries on the client side and idempotent behavior on the server side). Immediately erroring out on the client is usually going to lead to a poor user experience and might lead to inconsistent behavior.

kccqzy 7y ago
> so knowing where the client failed isn't actually useful for knowing the state of the request and what needs to happen next. Correct. Which is why the client should just error out and stop processing and return the error to the user, who will have more context and knows whether or not a retry is necessary or desirable. My argument is that your "resilient design around client-server communications" isn't necessary in the majority of cases, and is often unwarranted over-engineering. Poor user experience is fine, if they don't happen very often, and go away upon a retry. Even banks do that. It's fine. No one will be offended if your app shows an internal error message once a month (a five-minute outage in a month is still more than 99.9% availability).
- ubu7737 7y ago
  This is correct. In an authorization with a user waiting at the POS, you fail-fast and let the user retry. During the clearing/settlement phases, you don't have a waiting user. You're settling accounts and moving money. Nothing is allowed to fail silently.
- azylman 7y ago
  > the client should just error out and stop processing and return the error to the user, who will have more context and knows whether or not a retry is necessary or desirable... Even banks do that. It's fine If a user at a bank tries to transfer $10,000, gets an internal server error and retries because their balance hasn't updated (banks don't process these in realtime), and checks the next day and finds $20,000 gone, that's a big problem. The user can't be responsible for this, you need something more. You're not wrong that this isn't necessary in the majority of cases (updating your email address?) - but the majority of cases don't need distributed systems. By the time you're talking about distributed systems (which is the focus of this article and discussion), you absolutely do need this, in the vast majority of cases.
  - ubu7737 7y ago
    Avoiding duplicate processing is a very big part of compliance in banking transactions. Making mistakes in this area is somewhat common but very punitive for the institution that makes the mistake. As a result, design priorities are heavily skewed toward exactly-once processing of financial transactions.
  - foota 7y ago
    Eh, in that case you're asking for trouble by requiring the server to be successful. If I had to write an API like that I would definitely go with randomized tokens per logical request for dedupe on retries. If it's a user facing transaction it should be a transaction resource that's created and then the server does the retries imo, with the user able to view the status.
    - azylman 7y ago
      Exactly, given a timeout you can't assume the server is clearly successful (or unsuccessful!). That was my point, we're definitely agreeing :) Usually you'd generate some kind of idempotency key (randomized token as you said) and retry with that. You definitely can't just bubble that up to the user and assume things are fine

kccqzy 7y ago

> so knowing where the client failed isn't actually useful for knowing the state of the request and what needs to happen next. Correct. Which is why the client should just error out and stop processing and return the error to the user, who will have more context and knows whether or not a retry is necessary or desirable. My argument is that your "resilient design around client-server communications" isn't necessary in the majority of cases, and is often unwarranted over-engineering. Poor user experience is fine, if they don't happen very often, and go away upon a retry. Even banks do that. It's fine. No one will be offended if your app shows an internal error message once a month (a five-minute outage in a month is still more than 99.9% availability).

ubu7737 7y ago
This is correct. In an authorization with a user waiting at the POS, you fail-fast and let the user retry. During the clearing/settlement phases, you don't have a waiting user. You're settling accounts and moving money. Nothing is allowed to fail silently.
azylman 7y ago
> the client should just error out and stop processing and return the error to the user, who will have more context and knows whether or not a retry is necessary or desirable... Even banks do that. It's fine If a user at a bank tries to transfer $10,000, gets an internal server error and retries because their balance hasn't updated (banks don't process these in realtime), and checks the next day and finds $20,000 gone, that's a big problem. The user can't be responsible for this, you need something more. You're not wrong that this isn't necessary in the majority of cases (updating your email address?) - but the majority of cases don't need distributed systems. By the time you're talking about distributed systems (which is the focus of this article and discussion), you absolutely do need this, in the vast majority of cases.
- ubu7737 7y ago
  Avoiding duplicate processing is a very big part of compliance in banking transactions. Making mistakes in this area is somewhat common but very punitive for the institution that makes the mistake. As a result, design priorities are heavily skewed toward exactly-once processing of financial transactions.
- foota 7y ago
  Eh, in that case you're asking for trouble by requiring the server to be successful. If I had to write an API like that I would definitely go with randomized tokens per logical request for dedupe on retries. If it's a user facing transaction it should be a transaction resource that's created and then the server does the retries imo, with the user able to view the status.
  - azylman 7y ago
    Exactly, given a timeout you can't assume the server is clearly successful (or unsuccessful!). That was my point, we're definitely agreeing :) Usually you'd generate some kind of idempotency key (randomized token as you said) and retry with that. You definitely can't just bubble that up to the user and assume things are fine