- When the system is operating normally it asks for a different pair of characters each time. The fact that it is not doing this is a symptom of it being overloaded IMO.
- The bank cannot be expected to design computer systems that have the capacity to handle a run on the bank - it just wouldn't make any sense, and there are sound business reasons why you wouldn't want your computer systems to be able to smoothly handle a run!
Of course a bank can be expect to design systems that handle the numbers of customers it has. Anything less than that amounts to poor and shoddy service. NR have a system which is badly implemented either because the people they contracted to build it don't know what they are doing, or because NR are not willing to put up enough money to pay for a real and proper system (i.e. well designed and with adequate hardware and software to allow it to function well).
As an example of a system that works well, 24 hours a day, for many millions of people, look at Google. When was the last time that you got a timed out connection when you used Google's search facility. And that involves hefty database lookups which require significant horsepower (and/or an extremely well designed system). The Google system is so good, because if it weren't no-one would use it and Google would cease to exist. The NR system being bad, relatively speaking, reflects badly on NR.
I guess you don't have much experience of IT systems.
All IT systems are designed to handle expected volumes and peaks within a certain set of parameters. It would be ludicrous to pay for a system that could handle 75% of customers logging in at once when your normal volume is, say, 0.05 % of customers logging in at the same time.
Google is designed to handle Google's expected volumes, NR is designed to handle NRs expected volumes.
Ever heard of a Denial of Service attack? Where a hacker simulates many simultaneous http requests to bring down a website? This has happened in the past to Yahoo and Paddypower, and is the equivilant of what is happening to NR at the moment.
Lastly, even if it wasn't massively expensive to allow 100% of customers to withdraw at the same time, no sane bank would implement a system that could do that.
Oh, only about 15 years or so. Will that do, at all?
So, it is ludicrous to pay for a system that can accommodate even the majority (let alone all) of your customers at the same time? Someone better tell places like Tesco, for example, that they should reduce the number of cash registers in their stores, as Tesco seem to be under the impression that lack of resources in that area will result in their customers choosing to go elsewhere.
I can understand your anger askew70, but if you can find a bank with an online facility with the bandwidth that you require, I suggest that you bank with them, I am not so naive as to think that I am going to find one.
In answer to your last question, banks have been doing this for years.
I am not excusing it, just realistic. In the days when all retail banking had to be done in the branch, lots of branches would just close the doors early
because the queues inside were too long to be dealt with that day.
Different technology, same service.
If your expected peak capacity is .05%, then you might build in contingency to be able to handle peaks of 100 times that (i.e. 5%).
Anyway, my reason for posting was simply to point out that there is a reasonable explanation why their systems would be unresponsive right now. Not trying to get under anyone's skin
To take another example, as you don't seem to like my Tesco analogy: If a plumber installed a toilet in your house that simply failed to operate after it reached a limit of 5 flushes in any one day, then I suspect you'd be a wee bit upset. You can choose to be selective about which services you expect quality from, but I prefer to be more consistent.
I can have a crack at that one too
If everyone in your house had a bad case of the runs and needed to use the toilet at exactly the same time, but they couldn't, would you blame the plumber? Would you pay for and maintain individual toilets for each person in case this contingency should arise? Most people don't because they are happy to have enough toilet capacity for normal demand.
Okay, enough!I agree that its frustrating, but so far they haven't failed my service expectations. However, the situation continues for much longer then my opinion will certainly change. I'm willing to give them the benefit of the doubt for a couple of days in the current circumstances.
Service expectations should be based on what the service claims to offer. NR offer 24x7 access, and use this as a strong (and perhaps even the only) selling point for their service, but when tested they can't provide this. I am surprised that anyone considers this reasonable, at any time. It is not beyond the reach of a company with sizeable funds available to build a robust system to cater for hundreds of thousands, and perhaps millions, of customers, but it requires the commitment of the company offering that service, and NR's service has demonstrated their lack of commitment in that regards.
I managed to finally login a few minutes ago, for the first time in the last 42 hours. That, to me, falls very far short of a decent service.
On-Line Transaction Processing (OLTP) is a complex business. As the good general points out, many systems operate poorly when stressed. As an example of this with NR, I found last night that I was getting timeouts (the service unavailable message) after I had signed into my account. I found that (using firefox), if I reloaded the frame, I could get back to where I was (i.e. still signed in) as I posted earlier.I'd like to know if the design of the system allows the same number of successful transactions to be completed when it's under high load. If it's poorly designed it could actually be processing fewer transactions than when it isn't under high load. This could account for the long periods during peak load when nobody reported getting logged in and completing a transaction. This explanation doesn't need a conspiracy theory to account for the reduced transaction processing rate.
As Askew70 said a well designed system like google's (where programmers are given the time and respect necessary to do the job right) reacts well under load by not locking out all users. Any well designed system also uses dimensioning rules for expected processing requirement rates so that costs may be balanced with benefits.
Building the kind of capacity to cope with an extremely rare event such as this would be a ludicrous waste of money. It's unfair to expect Northern Rock to have such capacity available, and it isn't the least bit surprising that the system is next to impossible to access in the midst of this present panic. I have always felt though that the NR online system was rather sluggish under normal conditions and certainly this is something that could have been improved. But I regard that as a separate issue from what's going on right now. Even if normal service was more responsive, it's hard to see how it would make much difference under the kind of demand it's facing at present.
Google is not a comparable operation, IMO, as it does not require security authentication. A better example would be if amazon had a massive sale on. I doubt if it would cope any better. As other posters have pointed out, ticketmaster have struggled even when they know there is exceptional demand coming for a particular event. Contrast this with the airline industry who have been running OLTP systems for the last 40 odd years and see that difference when Ryanair have a sale. Experience counts and the banks are novices at this.
Has anyone that made a withdrawal request on Saturday actually seen the money leave their account yet? My transactions are still showing up as pending. They are normal "3 - 4 working day" withdrawals but I'd expect to see them processed by now. Normally my money spends a few days in cyberspace/NR's account on the way out. Do they manually process all of these transactions?
Askew70 - having disagreed with you initially about the comparison with google/the difficulties of OLTP, I now find myself agreeing with you. This is day 5 and the service has not significantly improved. I would expect any reasonably IT department to have made improvements by now. As you say, the lack of responsiveness to the problems (or quite probably the badly constructed system that makes it difficult for them to respond) diminishes confidence in their ability to conduct day-to-day internet operations.Despite the views of some people here that this level of online service is only to be expected, I completely disagree. This situation would obviously push anyone's online service pretty hard, but NR's service has spent the last few days compeletely unusable, for the most part. I am repeating myself here, but this technology is not rocket science, it is well understood and capable of being used to provide a very good service for those companies for whom quality of service is important. Based on the shoddy behaviour of NR's authentication process, and the fact that the online service itself is simply unreachable most of the time for several days now, this particular service has shown itself to be sub-standard.
I have drawn the comparison to Google's search service before and I will repeat that again too - if the Google service was unusable for an hour or two (let alone several days), people would be annoyed and would flock to an alternative searcing service, and would possibly complain to others later that Google's quality had gone downhill. And that is a free service to most people who use it. Why should we be so forgiving of the online service of a bank which we fund with our own cash and which has potentially serious implications for us when it is unavailable?
I don't think this is being fair on NR. No secure webservice could maintain its QoS given the flash crowd scenario that NR has experienced these last days. The compute time required to negotiate SSL handshakes for all of NR's customers runs into the order of 72 hours alone. Not to mention that the computation time needed for the DB back end would be several times that. The cost of over provisioning for that level of a spike makes no economic sense.I am repeating myself here, but this technology is not rocket science, it is well understood and capable of being used to provide a very good service for those companies for whom quality of service is important. Based on the shoddy behaviour of NR's authentication process, and the fact that the online service itself is simply unreachable most of the time for several days now, this particular service has shown itself to be sub-standard.
I don't think this is being fair on NR. No secure webservice could maintain its QoS given the flash crowd scenario that NR has experienced these last days. The compute time required to negotiate SSL handshakes for all of NR's customers runs into the order of 72 hours alone. Not to mention that the computation time needed for the DB back end would be several times that. The cost of over provisioning for that level of a spike makes no economic sense.
Nothing is insurmountable but the cost of provisioning for a system that could handle so many transactions at the same time just does not make sense economically. I'd rather see my bank put its funds elsewhere than have it wasted on resources for crazy "what-if" scenarios.At that stage, database access becomes the next expensive operation, and given that database technology has existed for a long time that is capable of handling load very well, there is no reason for this to be an insurmountable hurdle by any means either.
Of course there is room for improvement on QoS and reusing SSL connections is a technique that can speed things up. This could compromise security somewhat which means it's use in banking web services is limited. Higher security obviously has to take preference over higher quality of service in the banking world.The nature of the failure of the NR web service right now is probably compounding their problems. Once you get an SSL connection established, to proceed with the authentication stage, more often than not authentication fails. If you subsequently quit that window, you lose your SSL connection and have to establish a new one from scratch, leading to greater load on the server. The success of people logging in through refreshing the existing window, with SSL connection already in place, might be down to the fact that these re-fresh connections don't add to the "SSL load" on the server.
I don't think that the likes of ticketmaster or amazon have yet encountered a situation where up to 1.5 million customers were all trying to log in and perform transactional operations at the exact same time, and over such an extended period. I would imagine they would experience a lower QoS too given the circumstances.People have referred here to the likes of Amazon and Ticketmaster as examples of services that might well fare badly in this situation too. I have had poor experiences with the Ticketmaster site, and am no fan of it, but I haven't experienced it being unusable for days at a time. I have never experienced significant problems with any of the other heavily used online services that I make use us (Google, Yahoo, Amazon, eBay, etc.). The difference is, I believe, that those companies give adequate importance to the quality and reliability of their online services, whereas NR clearly has not done so.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?