http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660If their requirements are such that they don't require scalability, robustness, etc - then they don't need messaging within that bounded context. That being said, there is still value in having that bounded context raise events / publish notifications when user info is changed. http://ayende.com/3862/the-cost-of-messaging#comment38http://ayende.com/3862/the-cost-of-messaging#comment38Fri, 13 Feb 2009 06:25:40 GMTUdi, Agreed. I certainly think that a similar solution using RPC would be much more complex and likely more brittle. But people _aren't_ comparing that RPC solution to the messaging solution. They compare CreateUser and ValidateLogin to the messaging solution. http://ayende.com/3862/the-cost-of-messaging#comment37http://ayende.com/3862/the-cost-of-messaging#comment37Fri, 13 Feb 2009 01:27:11 GMTRe: We have the following guidance from Udi about this exact topic. That is one way of doing login. A highly performant and scalable way. Not the only way - not even when using messaging. I would argue that building an RPC based solution having similar performance and scale characteristics would be more difficult and complex. As such, I find that you're not calling out the comparative cost of messaging which is critical for readers in making the decision whether to adopt messaging or not. http://ayende.com/3862/the-cost-of-messaging#comment36http://ayende.com/3862/the-cost-of-messaging#comment36Thu, 12 Feb 2009 22:15:45 GMT@Pedro: You should make the site use JavaScript for a good User Experience; but when JavaScript is disabled, a fallback form post with a META tag that causes a refresh should be used. http://ayende.com/3862/the-cost-of-messaging#comment35http://ayende.com/3862/the-cost-of-messaging#comment35Wed, 11 Feb 2009 15:20:19 GMTSorry, the diagrams are not detailed enough. The cache is actually hidden behind a service interface that manages getting updates from the bus and updating its own local state. http://ayende.com/3862/the-cost-of-messaging#comment34http://ayende.com/3862/the-cost-of-messaging#comment34Tue, 10 Feb 2009 12:21:43 GMT"Steve, In a distributed system, how do you force a cache update?" I was thinking in a pub-sub situation where 'UpdateCache' is a subscriber to the 'NewUser' Looking for a way to avoid the 'please wait' senario. "Look at the last diagram, that is exactly what is going on. User Created is a published message that goes to all web servers, letting them know about the new user." Which you answered already above :) (I'm also interested in learning more about how Rhino DHT works) http://ayende.com/3862/the-cost-of-messaging#comment33http://ayende.com/3862/the-cost-of-messaging#comment33Tue, 10 Feb 2009 12:14:16 GMTYou can do the same using simple HTML. It isn't as slick, for sure, but it is certainly possible. http://ayende.com/3862/the-cost-of-messaging#comment32http://ayende.com/3862/the-cost-of-messaging#comment32Tue, 10 Feb 2009 10:34:59 GMTHi Ayende, Thank you for sharing this. I'm now working in a system where using a solution like the one you have described would be a great benefit. Unfortunately I have a problem; my web site needs to comply with the Web Content Accessibility Guidelines AA. This roughly means no JavaScript dependency for site functionality. :( http://ayende.com/3862/the-cost-of-messaging#comment31http://ayende.com/3862/the-cost-of-messaging#comment31Tue, 10 Feb 2009 10:25:39 GMTLook at the last diagram, that is exactly what is going on. User Created is a published message that goes to all web servers, letting them know about the new user. My point was that any way to inform the web servers to drop the cache was also a way to inform them about the new user http://ayende.com/3862/the-cost-of-messaging#comment30http://ayende.com/3862/the-cost-of-messaging#comment30Tue, 10 Feb 2009 10:09:35 GMTAyende, when you say you can't update the web servers when a new user is added, you said: "In a distributed system, how do you force a cache update?" But how are you managing the authentication servers sending the 'this user is gone' messages? You said you would publish a message from the authentication server telling subscribers the user is invalid, why would this not also be done for added users? http://ayende.com/3862/the-cost-of-messaging#comment29http://ayende.com/3862/the-cost-of-messaging#comment29Tue, 10 Feb 2009 09:24:07 GMTBoo, Not really. I am trying to make a point here. And SP has their place. CreateUser and ValidateLogin is NOT their place, but it make it easy to talk about certain things. http://ayende.com/3862/the-cost-of-messaging#comment28http://ayende.com/3862/the-cost-of-messaging#comment28Tue, 10 Feb 2009 08:53:17 GMTA guy who always supported ORMs now talking about SPs!!! Things change !!! http://ayende.com/3862/the-cost-of-messaging#comment27http://ayende.com/3862/the-cost-of-messaging#comment27Tue, 10 Feb 2009 06:43:00 GMTInteresting - I think I have a better idea of how you would approach it. Thanks for taking the time to respond. http://ayende.com/3862/the-cost-of-messaging#comment26http://ayende.com/3862/the-cost-of-messaging#comment26Tue, 10 Feb 2009 02:58:41 GMTTroy, It is not quite caching, as the notion of a local state that is important. http://ayende.com/3862/the-cost-of-messaging#comment25http://ayende.com/3862/the-cost-of-messaging#comment25Tue, 10 Feb 2009 02:48:43 GMTTroy, For something like SO, I would use a local persistent cache. It is unlikely that the data size is large enough to exceed common HD sizes for servers. But let say that it does, and we do want to ensure good response times for the users. At that point, I would apply the "not all problems are born equal" metric. That is, for SO, I would say that it is likely that the most viewed questions are going to be in the cache, so we have that benefit for the common case. For the uncommon case, I would probably make a sync call the get the data. It depends on too many factors to really answer in a good way. Ajax is a great way of breaking apart the page, and a loading indicator can do wonders for the user's experience, so it might very well not be necessary. I would try to avoid that, if possible, but it is still an option. http://ayende.com/3862/the-cost-of-messaging#comment24http://ayende.com/3862/the-cost-of-messaging#comment24Tue, 10 Feb 2009 02:45:38 GMTAfter I wrote the previous comment - something occurred to me: in a messaging-centric application, distributed caching (DHT, Velocity, memcached) becomes much more important (thus your work on DHT). It doesn't wholly solve the issues I raised above, but it would at least lesson the frequency at which they occur. http://ayende.com/3862/the-cost-of-messaging#comment23http://ayende.com/3862/the-cost-of-messaging#comment23Tue, 10 Feb 2009 02:43:49 GMTChris, Per web server. And I would use something like Rhino DHT, so it is a persistent cache. http://ayende.com/3862/the-cost-of-messaging#comment22http://ayende.com/3862/the-cost-of-messaging#comment22Tue, 10 Feb 2009 02:40:38 GMTI haven't worked in a messaging-centric system before, so forgive my naivete. Let's take StackOverflow as an example since we all know it. We'll assume for the sake of argument their dataset is too large to fit entirely into the server's memory... If they were to rewrite that site to be based on a messaging system and a user navigated to a question page for a question that was not yet cached on that server, how would you suggest handling it? I see three options here: 1) Have the page send a message requesting the question & answers. Use the JavaScript timeout you demonstrated in the article to pause for the response. 2) Send the message so that the cache is populated for the next request, but display a 404/some-other-error for the current request saying the data wasn't available. 3) Make the messaging synchronous and wait for the response in the same request thread (thus locking it). - My gut tells me solution #1 would result in a poor user experience and overly complicated the UI layer - it would also result in a *significant* increase in page requests. - Very few applications would say that solution #2 is acceptable, though certainly there may be some instances where you don't need the most up-to-date data (e.g.: Amazon's SimpleDb service does not guarantee each node will have the current state at all times). - Through the process of elimination #3 seems to be the best, but I am curious as to how performance would be impacted given the locking concerns. Your thoughts? http://ayende.com/3862/the-cost-of-messaging#comment21http://ayende.com/3862/the-cost-of-messaging#comment21Tue, 10 Feb 2009 02:39:56 GMTAyende, Do you have a sample code for the above? Kinda confused on: "The authentication service send the web server all the users he is aware off. The web server then cache them internally." When you say "cache them internally", is it a one time thing, I mean upon the start of the web server (IIS) or every time a browser is open and try to use the login page? And how long would be the retention of the cached will and the next time it will refresh? br, ca http://ayende.com/3862/the-cost-of-messaging#comment20http://ayende.com/3862/the-cost-of-messaging#comment20Tue, 10 Feb 2009 02:35:20 GMTNo, it is not. There are ways to work with that as well. It is simply require different way of thinking about this. http://ayende.com/3862/the-cost-of-messaging#comment19http://ayende.com/3862/the-cost-of-messaging#comment19Tue, 10 Feb 2009 01:59:06 GMTAyende, is it fair to say that messaging-based systems work better for non-read-heavy applications? Or, alternatively, an application that can locally cache all or most its data? http://ayende.com/3862/the-cost-of-messaging#comment18http://ayende.com/3862/the-cost-of-messaging#comment18Tue, 10 Feb 2009 01:52:25 GMTI think this is a great explanation of the cost of messaging and why it might be worth it anyway. Thanks. http://ayende.com/3862/the-cost-of-messaging#comment17http://ayende.com/3862/the-cost-of-messaging#comment17Tue, 10 Feb 2009 01:33:36 GMTSteve, In a distributed system, how do you force a cache update? http://ayende.com/3862/the-cost-of-messaging#comment16http://ayende.com/3862/the-cost-of-messaging#comment16Mon, 09 Feb 2009 23:49:03 GMTHow about if a new user registration forced a cache update ? Typically an email is sent out to a user after registration confirming their registration. I would gather new user registration would be far lower than login requests. (I don't personally like the idea of hanging up a login while you wait for a cache update) http://ayende.com/3862/the-cost-of-messaging#comment15http://ayende.com/3862/the-cost-of-messaging#comment15Mon, 09 Feb 2009 23:46:46 GMTI think if you are going to involve javascript in the posts then I'd go with what Aaron says and do the authenticate with ajax requests - I actually think this would keep the page code much simpler and reliable.. I also think that I explained myself wrong about locking, I don't think you have a deadlock situation, and if you did this would still effect the javascript solution, effectively leaving it trying again over and over for something that won't return. I'd prefer to stay at the server until the auth server can give me (the web server) an answer.. but I understand the problem with this hogging request handling threads.. http://ayende.com/3862/the-cost-of-messaging#comment14http://ayende.com/3862/the-cost-of-messaging#comment14Mon, 09 Feb 2009 23:39:55 GMTIt is much simpler, there is not threading whatsoever, it is just "execute this piece of code later". In essence, this is like thread sleep, which is very easy to understand. It also make most of the server code something like: if (data exists in local state) send else 404 http://ayende.com/3862/the-cost-of-messaging#comment13http://ayende.com/3862/the-cost-of-messaging#comment13Mon, 09 Feb 2009 23:34:55 GMTconfigurator, I do it either way. Usually with ajax form submit, but also with a redirect to a processing page. It depends what I expect the usual latency to be. If most requests are processed immediately, then it is ajax. If this is a lengthy process, then they go to a processing page. http://ayende.com/3862/the-cost-of-messaging#comment12http://ayende.com/3862/the-cost-of-messaging#comment12Mon, 09 Feb 2009 23:33:24 GMTYou're saying the javascript timeout model is more simple than an async web request? I'm not sure I agree with that... And yea, it takes server resources... kind of. It doesn't take a thread-- which is the most important resource as connections are plentiful. http://ayende.com/3862/the-cost-of-messaging#comment11http://ayende.com/3862/the-cost-of-messaging#comment11Mon, 09 Feb 2009 23:32:59 GMTAyende, I'm sorry, I didn't explain myself properly. Reading my comment again, I don't know what I was thinking :\ What I meant was not what would the actual message be - but what would the mechanism be. Would you use redirection or AJAX. i.e. Will the user notice a redirection on form submit, or simply a wait? And will he notice a redirection on the second request, or will the page 'magically' populate? I think I'd go with catching the form's submit in javascript, displaying a message and causing an asynchronous request. If the "wait and try again" message is received, cause another async request after the wait, and only when login is successful, redirect to an after-the-login page. Sadly, I haven't had the pleasure of working on scalable online systems; the only online systems I made were for closed small groups of internal users. That is why I'm always interested in your opinion as a more experienced developer - what would you do? http://ayende.com/3862/the-cost-of-messaging#comment10http://ayende.com/3862/the-cost-of-messaging#comment10Mon, 09 Feb 2009 23:29:08 GMTAnd, of course, async web requests still takes server resources http://ayende.com/3862/the-cost-of-messaging#comment9http://ayende.com/3862/the-cost-of-messaging#comment9Mon, 09 Feb 2009 23:21:46 GMT