May/June 2019 issue of acmqueue The May/June 2019 issue of acmqueue is out now

Subscribers and ACM Professional members login here

Distributed Development

  Download PDF version of this article PDF

Error 526 Ray ID: 50bc964c5d6cccc2 • 2019-08-25 09:37:23 UTC

Invalid SSL certificate








What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.


Originally published in Queue vol. 17, no. 1
see this item in the ACM Digital Library



Andrew Leung, Andrew Spyker, Tim Bozarth - Titus: Introducing Containers to the Netflix Cloud
Approaching container adoption in an already cloud-native infrastructure

Marius Eriksen - Functional at Scale
Applying functional programming principles to distributed computing projects

Caitie McCaffrey - The Verification of a Distributed System
A practitioner's guide to increasing confidence in system correctness

Philip Maddox - Testing a Distributed System
Testing a distributed system can be trying even under the best of circumstances.


(newest first)

David M. Karr | Sun, 30 Jun 2019 07:32:57 UTC

Am I understanding this correctly, that this model specifies that each payment executor is dedicated to the processing of a single account? This point may have been made in other questions/comments, but if this is correct, that clearly would not scale. I imagine it was specified this way to avoid trying to illustrate an overly complicated model, but reality is actually more complicated than this. I actually believe that this basic strategy has a lot of merit, but I wonder if projects attempting this approach fail because they didn't fully understand how to do this properly. In my own enterprise, we use Kafka for processing ecommerce orders, but there are significant problems with it, and some people think it's because of the use of Kafka, and are considering replacing it with other technologies, like ActiveMQ. I frankly think it's more likely that the architecture implementation and maintenance of the system is faulty, not the underlying technology, but I also believe that event sourcing is conceptually simple and hard to implement in reality.

Erik Eidt | Thu, 11 Apr 2019 21:40:25 UTC

?6. The server handling the user's request may also subscribe to the source-account log and thus be notified when the payment request has been processed. This status information can be returned to the user.?

The structure of the command to transfer a balance from one account to another is a composition of: a request to withdraw funds from one account, along with another command to deposit funds on success of the former.

Let?s make the structure of the command more explicit, to allow nesting commands, to support on error and on success actions, while also adding inquiry and posting commands. The larger command for transfer might be composed of the following sub commands:

a query (that gets the balance of the source account), and request to post the query result to the log for this transaction,

a request to withdraw funds from the source account, which includes: a command to execute on error (that might post the error message to the log for this transaction), and of course, a command to execute on success, which will include the following sub commands:

another inquiry into the balance of the source account, with request to post the query result to the log for this transaction.

a request to deposit funds into the target account, which is structured as the following sub commands:

an inquiry into the balance of the target account, along with a request to post the query results to the log for this transaction,

a request to deposit the funds into the target account,

another inquiry into the balance of the target account, along with request to post the query results to the log for this transaction.

As the transaction is completed, the user can see, in the log for the transaction, a consistent snapshot of the exact effect of the transfer on both the source and the target account, even though the withdrawal and deposit happen at different points in time and on different servers. This effectively performs a distributed join query for the user, at the exact right point in time for each of the data sources (the source account and target account).

name | Sat, 06 Apr 2019 14:06:01 UTC

The example OLEP solution for financial transaction processing is very overcomplicated and due to this is later criticised for not offering consistency. That is why it's more important to understand the business process logic than details of underlying technical solutions; once the business process is understood, onecan set requirements for the systems that are required to implement this process.

Leave this field empty

Post a Comment:

© 2019 ACM, Inc. All Rights Reserved.