Platform documentation
Features are important, but so is the integrity of the platform you're using. Performance, availability, and security are all crucial, so we've compiled some key information about the Mews platform.
Features are important, but so is the integrity of the platform you're using. Performance, availability, and security are all crucial, so we've compiled some key information about the Mews platform.
Back
Mews is a cloud-native, serverless, multi-tenant SaaS platform. This has many implications across all aspects of how Mews operates and how it fulfils various requirements and compliance. It’s important to look at Mews through the prism of this philosophy while reading other sections of this documentation, because it might be different from more traditional systems, and some requirements or questions are not applicable when considering the Mews platform.
From day one, Mews was built for the cloud. The system architecture was designed for cloud deployment and it utilizes all of the benefits this brings. Mews is not a system that was designed to run on-premises and later ported or adjusted for cloud deployment, which means that some processes or procedures work differently or are not happening at all.
There are multiple ways to operate within a cloud environment. On one end of the spectrum, you could be using only the low-level cloud services like virtual machines and handle everything else on your own. The advantage of this is that all cloud providers offer such primitive functionality and therefore it’s rather straightforward to switch them – although you need to have expertise on how to configure the servers, databases etc. and continually maintain it on your own.
On the other end of the spectrum, you could go beyond low-level functionality and use the cloud as a service, e.g. computing or storage services. That way, the cloud provider takes care of the configuration and maintenance – the disadvantage is that you are becoming more locked-in to your specific cloud provider.
We are a proud partner of Microsoft and use Microsoft Azure to its fullest potential. Therefore, we’re on the serverless side of the spectrum. We use services like Azure App Service for web application hosting, and Azure SQL Database and Azure Storage as storage services. Therefore, we don’t operate any virtual machines, web servers or database servers on our own – that is the responsibility of our cloud provider, including the compliance and security of such services.
These services have their own SLAs defined by Azure. We built our solution on top of that in a way that combines their services and SLAs together with our system, to guarantee our SLAs. We use the same technique to guarantee our compliance, security, disaster recovery and other aspects covered in more detail in further sections.
There is a single production “installation” of Mews platform that all of our clients use. That means our clients are always running on the latest version of the platform, with the same features and functionality available to anyone else on the platform (depending on subscription level). From a data perspective, data is not segregated, the storage is shared.
From a security perspective, it is actually very similar to a single-tenant system. There, we’d have to ensure that users with different privilege levels can access only the data they are granted access to. On multi-tenant systems, the tenant can be understood as another “layer” of privileges. Having a multi-tenant solution allows us to effectively implement above-enterprise or above-chain scenarios and deliver great guest experience, especially in the guest portal.
The only thing you need to use Mews platform is the internet and a web browser. Everything else, we take care of. We handle all the aspects that are covered in this documentation, and we strive to do them as well as possible while continually improving. It is our responsibility to ensure the system is fast, always available, has backups, is secure, complies with all legislations, is always up-to-date, accessible for everybody all over the world and usable for a wide range of users.
Customers are only responsible for keeping external records if that is required by law. In France, customers have obligation to keep the tax records on a secure external physical medium for the legally required period.
We use Microsoft Azure as a cloud provider, and we utilize the following services:
Some of these services are global with geo-replication and high-availability built in by Azure; some of the services are bound to a single region. We have two, fully-operational regions: the primary region in West Europe (Netherlands), and the secondary region in North Europe (Ireland). Our primary database is a high-availability cluster within the primary data center, with replicas in the secondary region. We have App Services, SQL Databases, Redis caches and Cosmos DB in both data centers, and the rest of the services are shared.
Besides the above, we use other third party services for various purposes:
When it comes to programming languages, we’re using C# and .NET on the backend, JavaScript/TypeScript and React on the frontend, and Flutter and Kotlin in mobile applications. On top of that, we utilize many open source libraries, frameworks and other programming languages and technologies. The complete list is evolving all the time, and you can see a full, up-to-date tech stack with all our services, infrastructure, tools, languages etc. at our StackShare.
The Mews platform runs in multiple instances called environments; some of them are public, some of them are private:
As a cloud-native system, our disaster recovery strategy revolves around data backups and the capability to restore them in case of an incident. All other services are “stateless” which means that in case of disaster, we are able to restore them without any loss of information. We heavily rely on features that Microsoft Azure offers in this area, plus we have our own levels of backups built on top of standard Azure features.
We use the premium tier of Azure SQL database with a replica in the secondary geographical region. This setup already has several backup layers and mechanisms out of the box, described in full detail in the Azure SQL database documentation. On top of that, we have our own backup processes. All of the options, both built-in and ours, are described below:
As a store for binary data, we use Azure Storage configured to use geo-redundant storage capabilities. The data is automatically replicated three times within the primary region and three times in the secondary region. The storage account also uses a soft-delete feature which prevents application specific issues and allows us to recover potentially corrupted data. Similarly to SQL database, we perform daily incremental backups of all data in the storage into backup storage that is ready for immediate usage in case of disaster affecting the primary storage.
We have Cosmos DB configured to be replicated into multiple regions. Cosmos DB transparently replicates the data to all regions associated with our account, and supports automatic failover in case of regional outage. Currently, we store only non-business-critical data to Cosmos DB (e.g. logs) and therefore we don’t have any additional layer of backups built on top of offered features of the service.
Our philosophy when it comes to deployments is to deploy as often as possible and the smaller the deployed change-set, the better. The main reason is that this helps us to deliver finished features and fixes to our clients as soon as possible so that they can benefit from them immediately. The secondary reason is to minimize problems during deployments and simplify investigation and rollback in case of any problems. All of our deployments cause no downtime for the end-user.
Our platform is not a single application that we would deploy en-bloc, but rather an assembly of systems and applications that work and communicate together and that have their own deployment schedules. There are three main categories of applications with respective deployment schedules:
We reserve the option of scheduled downtime necessary for system changes, although our goal is to never use this option. So far, we had to use it only once in 2013 when we were migrating our cloud provider from AppHarbor to Microsoft Azure. Since then, we have had no scheduled downtime.
It's important to distinguish deployment and release. Deployment is the moment when the change reaches the production. However, the change does not necessarily need to be available to all clients. The moment when the change is available to a client is called a release. Smaller changes, bug fixes, improvements or other non-critical things are released to all our clients as soon as they are deployed. However, for bigger or more critical changes, we stick to the following 4-step release process:
For all types of incidents, including security incidents, bugs, investigations or monitoring alerts, we follow strict resolution process. The process is documented in our internal knowledge base and all engineers and 24/7 support agents are familiar with that. Internally we use YouTrack as the main ticketing tool and single source of truth. Each ticket, regardless of severity, has a team assigned and is immediately communicated to the team using internal Slack channel.
For critical incidents, there is additional escalation flow and process:
The Mews platform works with very sensitive customer data, therefore security and data privacy are non-negotiable elements of the system. Our general approach in this area is that nothing should rely on people or their knowledge. All our security measures and internal processes are designed in that way; for example, while our developers are regularly trained on best secure coding practices, we do not solely rely on this for security. Our processes and frameworks are designed to prohibit the making of security bugs, or at the very least make it extremely difficult for a developer to introduce security issues into our system if it’s not technically possible to fully prohibit it. This is reflected in our security issue resolution process, which is described later. Our security strategy is governed by two main principles:
Besides these proactive measures, we are very often going through audits, certifications, due diligence processes and pen tests by 3rd party companies, either appointed by us (e.g. PCI-DSS, ISO) or by our prospective clients.
The best way to avoid any security issues is to completely eliminate the possibility of making them in the first place. This aligns with our serverless philosophy: we are not in control of hardware, operating systems, web servers or database servers. We are not able to misconfigure of any of these systems, and we are not able to forget to apply security patches etc. – this is the responsibility of Azure, who have big security teams. We use a very limited configuration of the Azure services, for which there are options to turn on some additional security features. To ensure we don't miss any of these, we use Azure Security Advisor, which notifies us about all such options, for example when Azure introduces any new features that could harden security of our systems. Thanks to all the above, our attack surface (from the system perspective) effectively gets reduced to the application code that we develop. For more information about Azure security capabilities, please refer to Azure's security fundamentals documentation.
As already demonstrated, our primary focus is on application-level security. In order to ensure that our system is secure, we continuously undergo penetration testing by cobalt.io. At any given point of time, a part of our system or a product is being pen tested and we make sure that the whole surface is covered by tests in a continuous fashion.
There are multiple approaches on how to address security vulnerabilities. We take pride in our approach and address every security issue in a post-mortem manner, meaning that we perform detailed root-cause analysis and then solve not only the individual instance but all similar instances in all of our products. On top of this, we put measures in place that prevent such issues from recurring in the future. As an example, if a problem is found in one of our APIs, we update our API framework in a way that it eliminates the issue from all of our APIs. Or we implement a static code-analyzer that can check for the issue in our codebase automatically, as well as new code that we produce. So even though a single product is being tested at a time, we apply our findings to all of them. For more information, check the Incidents section.
From the technical perspective, there is lot of things that we do to ensure security not only of the platform itself, but also of our clients. Here are some of them:
Great example of reducing attack surface is how we handle sensitive payment card data. Mews uses PCI Proxy as a card tokenization provider. Sensitive card data like number or CVV never even reach our infrastructure. As an example, let's consider a simple flow of receiving card details from third party (e.g. booking channel) and then charging that card:
Many types of attacks are rendered useless, due to the fact that our data storages do not contain the sensitive data.
Mews platform processes personal and other types of sensitive data, however we're not a standard processor-only SaaS service, so in order to understand all the data flows, it's important to distinguish the two roles Mews is in:
These two roles and operational modes of Mews are strictly distinct and the data never mix. And since we are a multi-tenant solution, a single physical person can have their personal data in N+1 copies in Mews platform. If the person had interacted with N of our clients (e.g. had reservation in N different hotels), then N customer accounts are stored and Mews is the data processor there. The "+1" represents another copy of the personal data that is stored in case the person signed-up to Mews as a user in order to use the "travel wallet" service. For this single copy, Mews is the data controller. We don't have any joint-controllership arrangement.
All kinds of data are stored in our Azure data storages according to the Infrastructure section of this documentation. We perform no archiving of the data and backups are held only for limited period of time.
The data enters the system either manually by employee of our client or are provided by their customers both directly (by sharing from travel wallet to the client) and indirectly e.g. via booking channels and our APIs. The data consists of personal details of customers of our clients who are mostly travelers from all over the world.
Our clients are able to record various data points about their customers like: first name, last name, second last name, date of birth, nationality, identity documents (passport, ID card, drivers license, visa), addresses, e-mail address, phone number etc. When it comes to payment card details, those are collected as well, however not directly accessible to our client nor to us. For more details, please refer to Security section of this documentation.
We process personal data in accordance with the data processing addendum that we sign with our clients. We are able to access the data when necessary to provide our service (e.g. investigating bugs or helping our clients in other ways based on their requests). We might use the data for internal statistical and analytical purposes, however they are always anonymized and we follow the contractual obligations. Also please refer to the Subprocessors section that lists 3rd party companies that act as subprocessors of the client data, or some subset of the client data.
We store personal data for as long as necessary, given the purposes for which they were provided or collected. Since we are processor when it comes to personal data that our clients (the controllers) collect, we are subject to their instructions on how to handle the data. It is responsibility of the client to ensure that the retention periods applicable to personal data are legally compliant. To allow our clients to manage the retention periods we give our clients options to:
For payment data, our clients can easily set the period, in days, after which the customer's payment card information will be automatically cleared. This is an automated process that when set, clears all card data that is attached to the guest profile. Clearing means that Mews does not retain the card token, and PCI Proxy will not have information about that card. When the process is set-up, the system clears every token from the Mews database and card from PCI Proxy is cleared.
When we hard-delete data from one of the Azure data storages we use, Microsoft follows strict standards for overwriting storage resources before their reuse, as well as the physical destruction of decommissioned hardware.
We provide means for our clients to fulfill data requests and data deletion requests coming from their customers. We also provide the user portal with messaging functionality that allows our clients to communicate with their customers easily. In case there is a request to our DPO (dpo@mews.com) that is intended for our clients and not for us, we forward such request to proper recipient.
The data enters the system only manually when the user populates or updates their profile. Or during sign-up. In order to provide the best experience when e.g. checking into new hotel, our users are able to record any data point that any hotel might need for check-in process. And it is up to the users to decide if they want to share their data with particular client of ours and to which extent.
On top of these shareable data points, we record usernames, passwords (hashed), means of 2FA authentication and other details necessary for frictionless usage of our platform.
Due to nature of the product, whose main function is to serve as a personal data wallet that can be used any time in the future to share the data with our clients, the data is stored for as long as the user has an account with us.
The user portal provides the users with all of their personal data that we store and a possibility to delete their profile. Other option is to contact our DPO directly at dpo@mews.com.
To support the delivery of our services, Mews engages and uses service providers that have access to certain user data. We select these third-party subprocessors and third-party processors very carefully, for third-party subprocessors, we require at least SOC 2, PCI-DSS or another industry equivalent audit/certification.
The following overview provides important information about the identity, location and role of each subprocessor
A third-party subprocessor is a service that we, as a data processor, utilize to deliver services to our clients (hotels) who are data controllers. Here is the list of third-party subprocessors:
The following list includes the service providers (certified partners) who are engaged by Mews to provide professional consultation and deployment services on behalf of Mews to specific clients (hotels) who purchase these kinds of services from Mews. It is important to note that not all service providers listed herein are utilized by all Mews clients. Here is the list of the additional third-party subprocessors:
A third-party processor is a service that we, as a data controller, utilize to serve our internal needs. You can find a list of all third-party processors that we use at our StackShare.
Mews group consists of the following affiliates:
Our approach to certifications is to judge them on a case-by-case basis in an on-demand manner. We are not proactive in this area, because even though some certifications can be helpful in learning to improve certain processes, and can provide assurance that what you do is considered best practice, we also see that some certifications have a hard time keeping up with new technologies and modern software development practices. Therefore, we only undertake the certifications that make sense to us or that are an absolute necessity for us. Currently, we have the following certifications:
Cookie management
Here you can manage your preferences regarding cookies:
Essential cookies
Essential cookies enable core functionalities of the website such as marking your data inputs, network management and accessibility.
Functionality cookies
These cookies allow a website to remember choices you have made in the past, like what language and currency you prefer, remember your name and email and automatically fill forms.
Analytical cookies
Analytical cookies help us improve our website by collecting and reporting information on how you use it.
Advertising cookies
Advertising cookies for delivering tailored and customized advertising.