Disney adds new designs to its MagicBand+ line-up, including Guardians of the Galaxy and Main Street Electrical Parade

flynnibus14 days ago

No - you're assuming they duplicated all this information into this 'magic band database' - there is no reason for such things. What you are really thinking about is there is some new master database of all things about a customer... that notion is independent of magic bands as a identity token. That is more about the modernization of their single platform.. and you don't really know how much was consolidated vs what simply stays within a particular realm and is simply SHARED to other realms for consolidated views. Your issues about 'much longer delays' are solved with caching systems. Disney has millions of customers... but there are only so many thousands on property at any point in time. For instance for ride terminals, caching 75k ticket records after their first use to speed up queries is pretty trivial to avoid dealing with blocking in a live database. Disney wouldn't consolidate everything into a single data model... instead you ensure many different platforms can interwork and share using common identifiers. So I don't mix a transactional history of everytime you scanned into a ride into the data store as your hotel reservation. Instead I ensure both systems use a common reference that can link your ride scan data to the same logical person who is holding a reservation. So when an application wants to see everything that logical person did.. that application can interact with those different systems and get data from multiple sources, but associated with the commonly shared identity. Don't confuse Disney having a consolidated VIEW of a customer to mean the data is necessarily consolidated itself.

flynnibus14 days ago

And that's where you are still wrong... 'that the magic bands access...' is non-sense. They don't access anything. They are a token that presents itself.. and the various systems you interact with then use that piece of data to cross reference an identity and entitlements for whatever is relevant for that application (a door system, a gate, etc). Applications would be querying a magic band platform to resolve band identifiers to other logical units. Applications like POS systems, keycard systems, entertainment platforms, etc. We don't know how much of the applications they consolidated into a single one.. vs ensuring separate systems being able to SHARE with each other.. but it's not really significant to this discussion. Statements like "It also has the unlock codes for the rooms they are authorized for" and "as well as the admissions media attached to that user" show a fundamental lack of comprehension of how such architectures work. Think of it as the band just being a temporary # given to you. The magic band system would be responsible for linking that temporary # to a logic customer entity. Each application would have it's own repository of what is relevant about your customer entity #. Like, you are allowed to open door 2355... while another platform may link that same customer # to a reservation... while another platform may link that customer # to a ticket entitlement. The point is... the systems all have a way to all link to the same logical 'customer' now.. where prior to Next Gen, everything was silos and it was much harder to cross reference things. The magic bands are just a way to present an identifier that can be trusted.. and provide a means to map that identifier to a logical identity that is used commonly through the NextGen experience. That mapping layer can have scaling and stale data challenges... where it's being tasked to cope with data that is basically worthless now because its accounting for data that will never be used. It's like cleaning out your attic after years... It's also possible that the newer generation bands have additional validation or other features that are holding systems back by having to support both a new and old model.. so deprecating the legacy use cases can improve functionality, security, and reduce complexity/cost to keep moving things forward. For a system of this size.. it's probably a mix of both.

AEfx15 days ago

I may very well be incorrect about the door opening procedure (I haven't paid on property prices since these things came out), but I never said any data was physically stored on the Magic Bands themselves. The point was, we are talking about a database that the Magic Bands access, which has a subset of the data the overall reservations system has. That's where glitches have happened in the past - the updates made to the reservation system by Guest Services, etc., copying the new data over to the database they directly access.

AEfx15 days ago

On the band itself, no - it's just a numerical code. But that code accesses a database specifically for those Magic Bands, containing the info that Magic Bands are meant (or were meant, depending on the data, i.e. birthdays and such) to be able to quickly access. They aren't hitting the reservations system directly every time they access data. Or there would be much longer delays between scanning and accessing the data they need immediately, and it would be millions more hits against the reservation system daily that would bog it down . I believe you will find that's why occasionally Guest Services has had issues syncing them up when updates are made to the reservations database - especially at the beginning. Because updated data wasn't always transferring from the reservations database to the Magic Band database.

HauntedPirate16 days ago

Valid point. I don't even think you'd have to go as high as 95% inactive to make a pretty solid case to pull the trigger on retiring the unused devices. I still don't trust Disney IT to do the job correctly, without impact. 😁 I'm still not buying a MagicBand. Or a DisneyBand. The fact that they fooled so many people into shelling out money for them in the first place should be a case study.

flynnibus16 days ago

There are other designs.. like tiered data stores. Plus the ability to basically partition records until they are needed. There is a ton you can do here.. But occam razor here... if you know you have 95% of the devices that will never be used again, it's just more efficient to retire them and deal with the exceptions than it is to keep building more support for them at expense.

flynnibus16 days ago

You clearly don't know how this stuff actually works... The bands are nothing but ID numbers, radios and the ability to do validation/encoding. They are essentially nothing more than a really big number assigned to you, with radio I/O attached so it can interact with NFC and RF devices. The far end is doing everything... Which is why your magicband can open your room without ever visiting the desk...

Brian16 days ago

That is correct. The bands have nothing "on them" except for a unique identifier which is used by the various touchpoints to query databases as to what the wearer has access to. When it comes to hotel doors, when the guest's assigned room is ready, the lock receives the identifiers of all the guest's bands and cards which are permitted to access the room. The more bands one has active on their profile, the more likely it is that one or more will fail encoding to the lock, which is one of the reasons why MB 1s are being mass deactivated. Other touchpoints, like LL and park entry, receive the unique identifier upon tap, query the databases to see if the proper entitlement(s) to enter are present, and return the approval/denial based on what the database says. If someone were to "hack" a physical MagicBand and read its data, all they would find is a long string of characters that is useless to them without access to the databases themselves.

CaptainAmerica16 days ago

Maybe I'm missing something then because weren't they adamant that no personally identifiable information whatsoever would be stored on the band? In your room key example, I think it works in reverse of what you described. It's not the band knowing how to unlock the door, it's the door knowing which bands are allowed to unlock it.

AEfx16 days ago

Oh, I'd be willing to bet there is a lot more there, especially if they actually had the intention of doing what they originally said they would do with them that never came to fruition. Example, you were supposed to be able to walk up to a NextGen Mickey, and he would know your name, and if it was your birthday, etc. In designing for something like this, it would have made much more sense to carry that data over to the MagicBand database itself, instead of having it hit the reservations system constantly to access that data. Both in terms of speed and database load on the reservations system. It also has the unlock codes for the rooms they are authorized for, as well as the admissions media attached to that user - or you'd be waiting with a delay like swiping a credit card transaction every time you used it, instead of the nearly instantaneous way they work now. It may not sound like a big difference, but when opening your room door or using it to enter a park, a second or two versus even 7-10 seconds really adds up (both for the user and overall operational efficiency). I'm pretty sure we would find that instead of just a simple link to your Disney profile, there is quite a bit of data copied over to the MagicBand database, which might be redundant at first blush, but operationally makes the whole system (and what it was intended to do) much more efficient.

HauntedPirate17 days ago

Personally, I think there should be a way for user's to permanently remove a MB from their inventory, with a pop-up window warning users and all that (I wouldn't trust Disney IT to do any sort of work around a mass MB disable without a debacle ensuing). I'm sure I have a dozen old AP cards and MBs that I could remove (I don't buy MagicBands, for the record) to help out the database size. ;)

Cariad17 days ago

I loved how it synched with the Water Show at California Adventure, even when I was strolling along Pixar Pier and not watching the show.

Cariad17 days ago

I'm glad I'm not the only one who has made a garland with them. I got a rechargable one on my last trip, I'm planning on using it for as long as it lets me.

mikejs7817 days ago

Pure tech speculation here - and sorry for those who aren't up on database design - but a common pattern for very large tables is to partition the table on specific fields, so part of the table is stored in one file and part in another. If, let's say, the table was partitioned on magic Band status, moving a large number of bands to inactive would significantly shrink that partition and could significantly improve performance, without having to physically delete the records. That being said, I don't see any reason Disney should invest in more storage to support a set of magic bands that are 99% unused and are over a decade old. If I were Disney I would announce the sunsetting of MB1 on a specific date. At that point, all those magic bands would be purged and unable to be reactivated without calling Disney support. Users who still have and want to use an MB1 could go to a page to click a button that keeps it active. That lets them clear out 99% of that data.