Let me provide a quick overview of the functionality you get with Tiles in case you aren’t familiar. Our users attach Tiles to items of value to them. From the Tile mobile app, you can ring your Tile if it’s in Bluetooth range of your phone or view a map with the last known location of your Tile. The Tile mobile app is also doing a background community find of any Tiles in the area and sending anonymous location updates to the Tile server. You can also click on your Tile and have it ring your phone in case you lose your phone.The image below is a graphic of our current Tile network. Every user is passively updating the location of other Tiles through the phone app. Every day we get over 1 billion location updates and we are finding 5.5 million things. Now that I’ve provided an overview of Tile’s functionalities, let’s dive into the Tile architecture. Tile’s use Bluetooth low energy (BLE) to advertise and can be in one of three states: shipping, advertising, or connected. When the user goes through the onboarding flow in the Tile mobile app, we ask the user to press the Tile button which starts advertising in shipping mode. The phone detects the Tile advertising in shipping mode, and completes the activation process, which puts the Tile into advertising mode. The Tile is now advertising every 2 seconds until a mobile app connects to it. The Tile mobile app is listening for this advertisement, and when it sees a Tile, the app connects to the Tile over BLE to retrieve its Tile ID. After the Tile and the app authenticate, the app will send a location update to our backend Tile Services API.In our current architecture, the phone stays connected to the Tile. This reduces the time required to ring the device. However, as we are moving into a world where a user may have multiple devices scanning for their Tiles (for example a Comcast Access Point and their phone) we want to move toward a connectionless model where we only connect to the Tile to ring it. This also helps with conflicts with other Bluetooth accessories. Let’s now dive a little deeper into how our Bluetooth communication works. Instead of using BLE directly via its existing protocol called GATT, we’ve created our own transport layer on top of GATT called Tile Over the Air or TOA. TOA allows for communication between a phone and a Tile (or between an access point an a Tile). We created our own transport layer to be able to have security and do the authentication between the phone and the Tile device. TOA utilizes two existing GATT characteristics for sending and receiving data via a client-server communication pattern. TOA commands are sent to the server (the Tile) using GATT Write without Response. TOA responses are sent to the client (the phone) using GATT Notify. Below is a diagram that shows the interactions between a phone and a Tile to read the Tile ID and authenticate. Now I’d like to explore our backend Tile Services infrastructure. Tile Services has a standard 3-tier web API architecture hosted on AWS. First we’ve got a load balancer layer using both Application Load Balancers and Elastic Load Balancers to balance our traffic across our EC2 boxes hosting our application servers. In the second layer, we have split our APIs into different services. Our Location service is our highest volume service and handles over 1 billion location updates a day. It has much different scaling needs than our much lower volume services. Our API service handles all the APIs for user and tile management. The reTile servers handle our reTile program which allows users to buy Tiles at a discount when their batteries run out. We also have a set of services to handle our Alexa and Google Home voice integrations. Finally, we have an event service that processes all the events generated by our mobile apps for analytics tracking. The third and final layer is our storage layer. Different data is stored in different places. Our location data is stored in redis with location history being on the Aurora DB. We recently moved the rest of our data from an NDB Oracle database to a more standard RDS MySQL solution on AWS. Now that I’ve described our current Tile architecture, I’ll share our plans for the future. Below is a diagram of our vision for the future of Tile. Instead of depending on phones alone to give location updates, we’ll also expect Access Points to provide location data. On top of our own physical Tiles, we are also looking to embed the Tile functionality into the 5 billion bluetooth devices sold this year, including headphones and laptops. This would mean that we’d scale from 20 million Tiles today to 100s of millions of devices providing trillions of location updates.I hope you’ve enjoyed learning about the Tile technology. Feel free to reach out if you have any questions or are interested in learning more! Jossie Haines has worked in the tech industry for 20 years and is currently the Platform Engineering Director at Tile where she integrates the Tile technology into the 5 billion bluetooth devices sold this year. She is also an advocate for women in the tech industry and has mentored at Girls Who Code, Technovations, and Plato. Jossie ran Women at Siri, and leads diversity and inclusion at Tile including the Women at Tile employee resource group, and company wide mentorship program.
Hey Jossie! Thanks for taking the time to share with the community here! Super impressed by your background and love that fact that your leading D&I initiatives at Tile and beyond. I've always read positive note about Tile and the workplace environment. I would be curious to get your personal perspective on how they receive the D&I efforts that you are pushing forward and what Tile does to help facilitate a more inclusive workplace?Thanks again for your time!
Hi Whitney! Thank you for the comment. One of the reasons I actually joined Tile is the support I received from the exec team at Tile in driving these D&I initiatives. About 6 months ago, we went through the exercise of redefining our core values at Tile and one of the 5 is Better Together. This really includes our belief that an inclusive diverse workforce will help us create better products and be more successful. I wrote a blog post on some of the D&I initiatives we implemented here: https://medium.com/tile-engineering/implementing-diversity-and-inclusion-at-tile-d25c7a5a73c3 and I'd be happy to chat more with you about it.
jgrayson·Jun 26, 2019
jgrayson·Jun 26, 2019
Hi Jossie, I'm curious what kind of progress you've made at Tile on the D&I front relative to compensation equity for racial and gender disparities. If you have insight, what would be or has been helpful in improving this to be equitable?
Hi Jessica, this is actually one area I still haven't had a chance to dig into yet. If I do, I'll reach out. Sorry for the late reply, was on travels this week.
jgrayson·Jul 01, 2019
jgrayson·Jul 01, 2019
Not a problem - was travelling myself! I think that would be a great start!
While it’s important to have these discussions, it's unfortunate that Jossie can write such a great technical post and the only comments/questions are about D&I. We need to regard women as technical leaders and not only for their views on diversity & inclusion. D&I is really important, but let's not let that conversation take away from or overshadow the technical perspectives women can contribute (we don't see enough of this as it is)
Hi Ainsley, thank you for your comment. I do appreciate you recognizing my technical contributions -- I wanted to take the time to write about something technical because a lot of my posts recently have been about D&I and I wanted to have a balance.
Thank you for the comment, Ainsley! A great reminder for us all to balance showcasing expert knowledge in all fields in tech as well as D&I in the community. Really appreciate your feedback!
Hi @jossie! Thank you so much for explaining the Tile technology, I love learning more about the tech that we use (and often take for granted) and this in-depth review is awesome. Can you go into more detail about the access points and how they work? From what I understand, this allows for the working distance of the Tile to be extended in addition to using other phones as hotspots.
Thanks for your comment! Love this question as this is one of the main two parts of my role at Tile :) I focus right now on two things - getting Tile firmware into existing Bluetooth devices so we get more Tile nodes, and getting Tile scanning into access points so we have more places that are scanning. We even have a partnership w/ Comcast who is putting Tile scanning into their set-top boxes. So how does it work? Well pre-access points we only had cell phones providing location updates for Tiles. When a phone sees a Tile advertising, it sends a location update up to our Tile Services backend. The access points can do the same thing, and now you have a fixed item that can help you find things. Let me provide a use case to show you the power of access points. Currently, if you have a Tile on your dog and he runs away while you were at work, you wouldn't know unless the dog triggered a community find on someone else's phone outside your house. However, if you had an access point at home, then as soon as your dog left your house, you could get a notification that the Tile is outside the area. Let me know if you have any other questions!
Now that I’ve provided an overview of Tile’s functionalities, let’s dive into the Tile architecture. Tile’s use Bluetooth low energy (BLE) to advertise and can be in one of three states: shipping, advertising, or connected. When the user goes through the onboarding flow in the Tile mobile app, we ask the user to press the Tile button which starts advertising in shipping mode. The phone detects the Tile advertising in shipping mode, and completes the activation process, which puts the Tile into advertising mode. The Tile is now advertising every 2 seconds until a mobile app connects to it. The Tile mobile app is listening for this advertisement, and when it sees a Tile, the app connects to the Tile over BLE to retrieve its Tile ID. After the Tile and the app authenticate, the app will send a location update to our backend Tile Services API.In our current architecture, the phone stays connected to the Tile. This reduces the time required to ring the device. However, as we are moving into a world where a user may have multiple devices scanning for their Tiles (for example a Comcast Access Point and their phone) we want to move toward a connectionless model where we only connect to the Tile to ring it. This also helps with conflicts with other Bluetooth accessories. 
Let’s now dive a little deeper into how our Bluetooth communication works. Instead of using BLE directly via its existing protocol called GATT, we’ve created our own transport layer on top of GATT called Tile Over the Air or TOA. TOA allows for communication between a phone and a Tile (or between an access point an a Tile). We created our own transport layer to be able to have security and do the authentication between the phone and the Tile device. TOA utilizes two existing GATT characteristics for sending and receiving data via a client-server communication pattern. TOA commands are sent to the server (the Tile) using GATT Write without Response. TOA responses are sent to the client (the phone) using GATT Notify. Below is a diagram that shows the interactions between a phone and a Tile to read the Tile ID and authenticate. 
Now I’d like to explore our backend Tile Services infrastructure. Tile Services has a standard 3-tier web API architecture hosted on AWS. First we’ve got a load balancer layer using both Application Load Balancers and Elastic Load Balancers to balance our traffic across our EC2 boxes hosting our application servers. In the second layer, we have split our APIs into different services. Our Location service is our highest volume service and handles over 1 billion location updates a day. It has much different scaling needs than our much lower volume services. Our API service handles all the APIs for user and tile management. The reTile servers handle our reTile program which allows users to buy Tiles at a discount when their batteries run out. We also have a set of services to handle our Alexa and Google Home voice integrations. Finally, we have an event service that processes all the events generated by our mobile apps for analytics tracking. The third and final layer is our storage layer. Different data is stored in different places. Our location data is stored in redis with location history being on the Aurora DB. We recently moved the rest of our data from an NDB Oracle database to a more standard RDS MySQL solution on AWS. 
Now that I’ve described our current Tile architecture, I’ll share our plans for the future. Below is a diagram of our vision for the future of Tile. Instead of depending on phones alone to give location updates, we’ll also expect Access Points to provide location data. On top of our own physical Tiles, we are also looking to embed the Tile functionality into the 5 billion bluetooth devices sold this year, including headphones and laptops. This would mean that we’d scale from 20 million Tiles today to 100s of millions of devices providing trillions of location updates.
I hope you’ve enjoyed learning about the Tile technology. Feel free to reach out if you have any questions or are interested in learning more! Jossie Haines has worked in the tech industry for 20 years and is currently the Platform Engineering Director at Tile where she integrates the Tile technology into the 5 billion bluetooth devices sold this year. She is also an advocate for women in the tech industry and has mentored at Girls Who Code, Technovations, and Plato. Jossie ran Women at Siri, and leads diversity and inclusion at Tile including the Women at Tile employee resource group, and company wide mentorship program. 
