Infrastructure & Environments

General

For us at SCAYLE, the security, availability, and elasticity of our services are top priorities. Therefore, we rely primarily on established best-of-breed technologies that meet our high standards. This includes providers such as AWS, Cloudflare, Datadog, Akamai, and GitLab.

The SCAYLE Engine stack can generally be devided into four layers:

1. Edge Services such as Web Application Firewall (WAF) and Content Delivery Network (CDN)
2. Compute Services that host our applications
3. Storage Services that store data
4. Operations Services to manage deployments and monitor our workloads

At the heart of the SCAYLE offering is our SCAYLE Core Engine which is hosted on the managed Kubernetes service AWS EKS. By using AWS EKS as our foundational technology, we ensure the elasticity of our infrastructure while maintaining flexibility in operating it.

The SCAYLE Core Engine utilizes AWS managed databases to ensure fault tolerance and data loss prevention.

Cloud Provider

AWS is our preferred cloud provider and allows us to operate our services globally at scale. We are using many managed services of AWS such as AWS EKS, OpenSearch, ElastiCache, or DynamoDB.

We are operating our services in two main regions of AWS, EU (Ireland) and US (North Virginia). Our services run always redundant across multiple data centers (availability zones) in these regions.

Multi Tenancy

The SCAYLE Core Engine can be structured into two primary layers - the compute layer and the storage layer.

Our application layer is hosted on a multi tenant infrastructure stack where multiple tenants share large Kubernetes clusters. This resource sharing strategy allows us to react fast and efficiently on traffic peaks.

Critical data is always strictly separated between tenants. Each tenant gets their own Database to store sensitive data of their customers. The underlying compute nodes are usually shared as well.

Security

At SCAYLE, we understand the paramount importance of maintaining the highest standards of security to safeguard sensitive data. One of the main principles that supports our security model is defense in depth, which means that we implement several layers of security. This principle gives us assurance that even if one security control fails, the others will still be in place, thus making an attack more difficult and giving our security engineers more time to detect and stop the attacker before any data is compromised.

Below you can find several examples of security controls that make this possible for us.

Intrusion Detection and Prevention

We employ Intrusion Detection and Prevention Systems (IDPS) to continuously monitor network traffic, making use of both signature-based and behavior-based methods to swiftly identify and block any potential attacks.

DDoS Protection

Traffic Filtering

Our traffic filtering mechanisms effectively identify and divert malicious traffic at the network's edge, preventing service overload and maintaining uninterrupted availability. The edge network we use is capable of withstanding some of the largest DDoS attacks recorded. Together with monitoring and alerting, we are able to quickly respond to attacks and adapt to changes in the threat landscape.

Scalable Infrastructure

Designed to dynamically scale, our infrastructure acts as an additional line of defense against DDoS attacks, ensuring seamless performance even in the face of unforeseen challenges.

Authentication & Authorization

Least Privilege Principle

Strong authentication and authorization primitives support our efforts in implementing the principle of least privilege, which can heavily reduce impact of a successful attack.

Role-Based Access Control (RBAC)

We use Role-Based Access Control (RBAC) to ensure that access is strictly limited to authorized individuals based on their role and job function.

Encryption

Transport Layer Security (TLS)

We employ Transport Layer Security (TLS) protocols to secure communication, encrypting data in transit between servers, clients, databases or any other networked devices.

Data-at-Rest Encryption

The data stored within our infrastructure is shielded with encryption, providing protection against unauthorized access, even in the event of physical compromise.

Vulnerability Management

Regular Scanning

Our proactive approach involves regular vulnerability scans to identify and promptly address weaknesses, minimizing the risk of exploitation.

Patch Management

A robust patch management process ensures that our software and systems are consistently updated with the latest security patches, maintaining the highest level of protection.

Software Supply Chain

We also monitor our software supply chain by generating and importing Software Bill-of-Materials (SBOM) and scanning them for vulnerabilities in the packages that we use.

Logging and Monitoring

We utilize several logging and monitoring systems to be able to:

1. Detect attacks as early as possible throughout their lifecycle.
2. Retrospectively analyze activity within our systems after an incident occurs.

Environments

SCAYLE provides three environments as a default.
Each environment targets a specific use-case.

Live Environment

The live environment is the environment which should be used in production.
This is the environment you have to connect your production Storefront and ERP with. It is set up to achieve high availability and scalability.

It runs with the latest stable version of SCAYLE.

Test Environment

The test environment is intended for use as your primary testing platform. This environment is not designed to handle production-level loads and has some scalability limitations.

It runs the same version of SCAYLE as the 'live' environment.

Preview Environment

The preview environment is the environment which should be used for trying out new upcoming features and test your applications & systems with the upcoming SCAYLE release.
This environment is not meant to be used with production load and comes with some scalability limitations.

It runs with the upcoming version of SCAYLE including the features which will get rolled out to the live & test environment.

Data Replication

The data replication feature enables seamless data transfer between different environments, such as from a preview environment to a live or test environment, or vice versa. This functionality empowers users to configure changes, such as restructuring the Shop Category Tree, in a test environment before pushing the tested setup to production. This practice mitigates the risk of misconfiguration, which could potentially lead to downtimes and revenue loss.

Within the SCAYLE Panel, users can easily select different data sets and transfer them between environments with just a few clicks.

Available Data Sets:

• Translations
• Roles
• Master Categories
• Shop Categories
• Search Configuration
• Pages
• Redirects
• Navigation
• Default Filters

As a security measure, every data replication process requires approval from authorized users. The user interface provides comprehensive insights into the data replication progress, ensuring that users are informed about every step of the process. In the event of any issues, the replication process is automatically halted, and the data is rolled back to ensure the integrity of the system is maintained, preventing any adverse effects.

Rate Limits

Rate limits control the number of requests per unit time.
Each Environment (Live, Test, Preview) has their dedicated rate limit settings.

General

Rate Limit Scopes

Most API endpoints belong to a rate limit scope such as stockWrite, productRead, etc.
Each scope defines its own rate limit, meaning that there might be no more than X requests within Y minutes to an endpoint of the particular scope.

It is important to note that every rate limit scope is isolated. Moreover, there are usually dedicated scopes for read and write operations. For example, if you have reached the limit by adding new stocks in the system, you can still retrieve stocks for a specific variant.

If the endpoint's scope is not mentioned, the amount of requests is not limited.

Rate Limit Header

Every API response includes the following rate limit related headers:

Response Example

The response for an exceeded rate limit is as follows:

json

Copy

{
    "errors": [
        {
            "errorKey": "RATE_LIMIT_EXCEED",
            "message": "The request rate limit exceeded. Please try again later.",
            "context": {}
        }
    ]
}

Live Environment

Admin API - Rate Limits

Storefront API - Rate Limits

There are no rate limits for the Storefront API defined.

Test Environment

Admin API - Rate Limits

Preview Environment

Admin API - Rate Limits