Architecture Overview

Chat infrastructure

Candidates can access the conversational assessments they are invited to from any modern browser. Each conversational assessment session has security settings and features that process and protect candidate's data while ensuring ease of access. All of these clients connect to secure servers to provide access to file sharing, code writing, compiling, and engaging with Adaface chatbot, Ada. Our chat infrastructure is comprised of the following components:

Metadata storage servers

Certain information about the conversation with the bot that is useful for creating a good user experience or considered as secondary elements in the overall conversation is called metadata. This metadata includes any files submitted by the user and proctoring information collected by our bot during the assessment. Dedicated storage services are deployed for different types of secondary data based on function and format. Storage servers with sync support and version history are deployed for relevant data like coding editors used during the chat.

Chat databases

Primary information about the chat is stored in a MySQL-backed database service and is sharded and replicated as needed to meet performance and high availability requirements. Primary conversation data acts as a single source of truth for every conversation with the bot and stores important assessment information helpful in administering the assessment and scoring the candidates' performance.

Organization databases

Organization information critical to conducting a chat - assessment data, customizations, settings, and information required for secure candidate authentication is stored in a MySQL-backed database service and is sharded and replicated as needed to meet performance and high availability requirements.

Metadata servers

The Metadata servers are responsible for cleaning, processing, and serving secondary data collected during the assessment.

Chat servers

Our chat servers are built to automatically scale based on a surge of concurrent conversational assessments. They handle the logic, data processing, and data synchronization of all primary data collected during the assessment.

Compiler servers

This is a separate service dedicated to supporting code compilers. Adaface conversational assessments support 30+ programming languages. To enable concurrent code execution and compilation functionality for candidates, our compiler services are kept on auto-scale infrastructure.

Dashboard/ App Infrastructure

Adaface recruiters can access their Adaface dashboard/ account at any time from the web and mobile clients, or through third-party applications connected to the Adaface application via our integration APIs. All of these clients connect to secure servers to provide access to the Adaface dashboard, access/ create/ edit Adaface test library, access/ create/ delete candidate invites, view candidate scorecards, and manage the candidate pipeline. Our dashboard infrastructure comprises of following components:

Metadata storage servers

Metadata/Secondary data collected from candidates during the conversational assessment is used by the Adaface application to generate scorecards. This metadata includes any files submitted by the user and proctoring information collected by our bot during the assessment. Dedicated storage services are deployed for different types of secondary data based on function and format.

Chat databases

Primary information about the chat is stored in a MySQL-backed database service and is sharded and replicated as needed to meet performance and high availability requirements. The stored assessment information is used to score the candidates' performance and report to the recruiters in real-time.

Organization databases

Organization information required for access management, storing purchased assessments, and administering the assessments are stored in a MySQL-backed database service and are sharded and replicated as needed to meet performance and high availability requirements.

Secondary app servers

Adaface secondary app servers are responsible for scheduling and running automated tasks and notifications. These sub-services are responsible for automating recruiters' workflow and are customizable. Automated tasks include monitoring conversational assessments and ending the unended sessions. They also take care of canceling unused invites so that recruiters can claim the credits and use them for more invites. Our dedicated notification sub-services are responsible for alerting recruiters and candidates via emails. This includes sending reminder emails for inactive candidates and custom test request email notifications.

Primary app servers

Adaface Primary app servers are built to automatically scale based on recruiters' usage. They handle the logic, data processing, and data synchronization of all organization data. They are responsible for authentication, customization, and accessing entire organization data. Security is built into multiple layers of our app servers ensuring that every action is logged and served only based on a user's roles and permissions.

Infrastructure: Behind the scenes

Our engineering team works continuously to innovate and implement secure practices in every layer of our applications. Here are some common segments:

Data centers

Adaface production systems are housed at third-party subservice organization data centers and managed service providers located in the United States. These third-party service providers are responsible for the physical, environmental, and operational security controls at the boundaries of Adaface infrastructure. Adaface is responsible for the logical, network, and application security of our infrastructure housed at third-party data centers.

Encryption

Adaface data at rest is encrypted using 256-bit Advanced Encryption Standard (AES). To protect data in transit between apps (currently API, or web) and our servers, Adaface uses Secure Sockets Layer (SSL)/Transport Layer Security (TLS) for data transfer, creating a secure tunnel protected by 128-bit or higher Advanced Encryption Standard (AES) encryption. Similarly, data in transit between an Adaface client (API, or web) and the hosted services is encrypted via SSL/TLS.

Certificate pinning

Adaface does certificate pinning in modern browsers that support the HTTP Public Key Pinning specification in most scenarios and implementations. Certificate pinning is an extra check to make sure that the service you’re connecting to is really who they say they are and not an imposter. We use it to guard against other ways that skilled hackers may try to spy on your activity.

Perfect forward secrecy

For endpoints we control and modern browsers, we use strong ciphers and support perfect forward secrecy. By implementing perfect forward secrecy, we’ve made it so our private SSL key can't be used to decrypt past Internet traffic. This adds extra protection to encrypted communications with Adaface, essentially disconnecting each session from all previous sessions. Additionally, on the web, we flag all authentication cookies as secure and enable HTTP Strict Transport Security (HSTS).

Key management

Adaface’s key management infrastructure is designed with operational, technical, and procedural security controls with very limited direct access to keys. Encryption key generation, exchange, and storage are distributed for decentralized processing.