DL Connection aren't effected. They don't depend on DL for operations. It's done by the carrier itself.

I too ran into trouble at HSV. My wife and I were scheduled to travel to AUS via ATL this morning departing at 6:40am. We got a notice on the way to the airport that I was rebooked on the 5:25am flight and would arrive at 11:49pm tonight with a connection at ATL and MSP. She was rebooked on United departing around 6am through Houston and arriving this morning, but we arrived too late at the airport for her to make that flight. I have business in Austin on Wed afternoon and all day Thursday and we were only going a day early to spend time with family there. We canceled her flights and supposedly with receive a full refund plus a $200.00 voucher. I changed my flight until tomorrow morning and was also promised a $200.00 voucher. Now I am trying to check into my flight tomorrow and am getting a notice that the ATL to AUS segment is overbooked and if I would be willing to take a later flight. Tomorrow might not be so much fun either.

The GDSs don't hold the inventory, they are connected to the airline reservations systems and when you book with the GDSs it writes your reservation to the same monolithic airline reservation application on the back end we have been talking about being down all day.

If it was as easy as putting it in the cloud the airlines and banks would have done it. If you are so convinced that the problem of stateful active active over high latency for sequential immediately consistent transactions is trivial you should start a software company.

From my perspective those who got to sleep in the airport are lucky. My flight was continually pushed back and moved until they finally cancelled at 3 AM (9pm original). Then I was on hold over amy hour with diamond desk to rebook because the app wouldn't let me rebook and as far as it said I had no flight scheduled.

Finally made it out, missing my first meeting and getting no sleep.

Industries that provide such crucial service cannot be left to regulate themselves with respect to pax compensation and minimum standards of service when it comes to IRROPS. History proves that it is not long before other carriers follow suit and it becomes a race to the bottom. I am not going to hypothesise what it may or may not lead to, but airlines will always compete on price. Airlines will always try to do something on the cheap in order to make more profit, so having legislation imposing minimum compensation and duty of care requirements would provide that safety net for pax that they deserve.

I don't think anyone is saying it is trivial... But I also don't think it needs to be that hard either. I see a few possible solutions to this problem (I am by no means an expert here):

1) DB failover: redundant DBs that automatically replicate and self-elect a master. Requires 3 or more members so you can have a quorum during master election. During normal operations, all reads and writes happen to an appointed master instance. All instances send "are you still online?" Heartbeat messages to each other to verify status, and slaves replicate data from the master as soon as it is written. If the master ever goes offline, the remaining members vote and elect a new master, automatically resuming operations.

2) blockchain-like distributed ledger. Biggest problem I see with this I current implementations is significant time delay while transactions are verified (proof of work currently takes lots of time, by design). But on the upside, even "untusted" parties can help contribute. Doesn't make a lot of sense for an airline.

3) fully redundant DBs: similar to a raid disk array. Writes happen across multiple DBs in parallel. Writes are verified for congurancy across all mirrors when a read occurs. If a mirror drops, the set is degraded, but still remains functional until the mirror comes back online. Biggest downside to this approach is the additional time needed to verify reads, which may not scale fantastically. But then again, we're talking milliseconds... If you have to wait a few extra ms to confirm that seat/ticket/weight balance call/whatever, it's probally not the end of he world.

Honestly instead of a dumb 58 second video from the CEO, I would just like them to come out, and admit what really happened.

There were no power outages in ATL that night, unless they are on some magical grid that only goes to them. (I am sure Georgia Power is scratching their heads on that one) :)

Tell people what really happened, what was done to fix it, and how you will work to avoid this happening in the future. Marketing must think the current approach is better, but the truth will go a long way for DL going forward.

DR's dont always work, it takes one outdated piece of equipment in a data center to crash the whole thing, etc. just admit your mistakes DL.

Did you read some documentation on exactly what the problem was that none of us have seen yet?

The amount of "I can't believe they didn't have a backup system!" naivety and general speculation about something no one here clearly has knowledge of us appalling.

Can we keep all the armchair IT quarterbacking out of this until we have some sort of definitive information about what happened and have someone who can start a post with "I AM an expert"?

I think it's better that Delta is focusing on service recovery first and worrying about blame second. When Delta knows more, I bet more info will come out.

No it's not scratching its head, it would seem Georgia power already pointed the finger at Delta.

http://www.nbcnews.com/business/trav...ailure-n625806

I'm sure Georgia Power was being pro-active, as they sensed they were going to be thrown under the bus by DL.

Not traveling until Saturday. I sincerely hope this mess is resolved by then.

A company the size of DL probably has almost a mini-power station either near by or even on campus for its data center. Thus no other power customers need be effected.

Fixing it to ensure you have enough power for a data center in case of power failure is not easy. Older DCs weren't designed with the power consumption backup that today's DCs need. Upgrading is neither cheap, nor easy. I worked at a DC providing support for 5 hospitals and all associated systems. At the time we upgraded power backups, they only could produce 70% of needed power. This was a data center that only ten years ago had power backup upgraded.

The speed at which technology has come into play has vastly exceeded that which data centers wouldve needed and been designed for only a few years before. Every server, every router, every computer or other electronic adds to the power demand. To replace those backup systems in general means taking the whole system down. In the case at the data center I worked that meant being without any computer technology for nearly 12 hours for 5 hospitals. Mind you this is a small data center. The likes of DL'S would be many times bigger.

As for the reason, a wait and see is best in cases like this. At this stage everyone wants to not be the one responsible and will put out PR trying to touted that. Wait a week and we'll have a clearer idea what caused this to start.

That is awesome!!!

I slightly disagree with you, DL is putting out the BS in hopes that the answer will be "good enough" and people will forget.

Did you ask for, or were offered, a hotel?