Once every week, our development team shares lunch and watches a video on some new code, new technology, or maybe something from a recent technology conference online. It's a continuation of the "Lunch 'n Learn" program we started at LoopNet several years ago. This week and last week we watched Udi Dahan's presentation at the London User Group on his alternative to the traditional n-tier web application architecture.
http://skillsmatter.com/podcast/open-source-dot-net/udi-dahan-command-query-responsibility-segregation/rl-311
Dahan attempts to make the case that the current data/business logic/presentation layer hierarchy is not only outdated, but fails to deliver on things such as determining user intent. Instead he claims that systems should be architected by establishing pre-calculated, cached copies of data on a per-query basis to be used for validation and determination of whether UI requests to the database, or "commands", should be allowed to execute. There's more to it than that, of course, but the main thrust of his argument is that, since data is always already inherently stale, that it doesn't matter how stale it is, and it should also be stored out somewhere in some persistent view model to be used for "decision support" as to whether or not to allow "commands" to be accepted. Once accepted, he states that it is perfectly reasonable for those commands to take hours to process, thereby dramatically reducing the load and contention inherent in most n-tier web applications that deliver data immediately, or close to it. The subject of "does your data need to be up-to-date" has come up myriad times in our User Group meetings, so I thought it would be appropriate to discuss.
I feel that while he makes some good points on determining user intent, he misses the point completely on his analysis of when data should be allowed to be stale and processes not be handled real-time. I am going to go through two scenarios he presented and explain why I feel that he doesn't make his case.
In his first scenario, Dahan uses a seat-reservation and ticketing system as an example. He describes a scenario where a user would click on 4 seats, attempt to reserve them, then find one of them taken when they go to check out. At that point they would go back and select a new block of 4 seats, have a similar issue where one or more are taken, and then have to go back and find another block of seats. His argument is that the UI should simply be asking "how many seats do you want, and do you want them together, and in what area/what price"? I'm with him to this point. However, he states that once the UI has gathered that data, the next step should be to inform the customer with a message saying "Thank you for the request. We will send you an email confirmation shortly." No other confirmation, no approval that the seats are available, nothing. I as the user might have to wait as long as two hours to find out whether or not my tickets are actually purchased. And if the request fails, I might have to stop what I am doing and go back and repeat the process again. Dahan's argument is that since we know we have 4 contiguous seats somewhere, we should be able to fill the request 99% of the time, and the "feel-good feedback" of "we'll get to you with a confirmation later" is enough to satisfy the user. I think this is poor customer service, and depending on how things go, I would use a site like Ticketmaster or some other site that could immediately confirm my seats rather than a site designed this way so I could be completely assured that my transaction is done and there is nothing left for me to do to acquire my tickets.
Dahan even goes so far as to suggest that ATMs follow the same model, that it is not necessary to go to the bank directly when a customer withdraws money, that they should be able to persist enough data out into the world so that ATMs could decide whether or not to dispense cash without the issuing bank's direct involvement. In fact, he goes on to state that this actually helps the banks because it encourages overdrafts in the case where a husband and wife both withdraw money on the same day, not knowing that their bank is not actually approving their withdrawals. Dahan claims this is a good thing, because all banks love overdraft fees. I find this type of attitude underhanded, and would cease doing business with a bank that designed their system in this fashion. Further, if I call my bank and report my ATM card stolen, they better be able to stop any use of it immediately, and that's not available in a system of this nature.
To me, real time data is at times critical and necessary, and to employ this sort of distributed caching system across the board seems naive and at times irresponsible. Systems Architects should be able to deliver their data immediately when requirements call for it rather than try to push their inefficiencies or inability to solve the problem back on to the user by making the user wait hours for ticket approvals...or overdraft their bank accounts because the system was incapable of a real-time approval call.