Basic Product Architecture
The DirectScale Platform is made up of two layers, the DirectScale Commissions Service (Disco) and CloudSpark.
Disco manages commission payments and backend systems. It also allows you to integrate with third-party systems like Third-party Logistics Providers (3PLs) and payment processors. We also provide a Public API resource that communicates with Disco, allowing you to build your own web applications. Disco’s system hardware is separated for each client, making it more secure.
CloudSpark manages all Admin portals and customer-facing web applications. Its features are multi-tenant; meaning, they share software and hardware for all DirectScale clients.
If you’d like a deeper look into the Basic Product Architecture, check out DirectScale’s Developer Documentation.
The DirectScale Platform is entirely cloud-based, primarily working in Azure. Its applications are .NET web servers with Single Page Applications (SPAs) built within Angular. The Platform also uses a variety of other tools for system management. These include:
Route 53 in Amazon Web Services (AWS) for DNS management.
Azure PaaS (Platform-as-a-service) technologies and IaaS (Infrastructure-as-a-Service) technologies, implementing Azure SQL and Azure VMs where appropriate.
Docker containers manage those with Kubernetes.
Global Scale vs. Web Scale
We think about scaling in terms of load and global presence. Most clients experience regular load spikes on their web traffic. This usually occurs at the end of commission periods when users are more active, trying to get last-minute orders in and check their stats to make sure they qualify for ranks and promotions.
Azure helps to handle the load. Our hardware infrastructure has alerts on high CPU, memory, and requests to scale out automatically and scale up this kind of load when needed. We address the global scale by using Azure CDNs, which Akamai backs. This makes content files like images, HTML, JS, and CSS locally deliverable via CDN caches.
Operating at a Global Scale
We use the best practices as we develop and deploy code, designing our software to meet your needs using these questions:
Do I have visibility into my services?
Is my code available and performing?
Is my code resilient?
Is my code vulnerable?
Is this feature extensible?
Is this operation repeatable?
Should I build a script/process?
Here are a few of our guiding principles:
We have to be backward compatible in all APIs; mainly, because our clients have custom code in our extensible areas.
We regularly look at single points of failure and have recovery plans with warm standby databases and services.
With some of our applications being multi-tenant, we ensure all service calls are for the right client. To ensure they are correct and have valid users, we compare data in the authentication tokens with the origin domain and site of the requests.
Vulnerability: Security in a Global Environment
We encrypt sensitive customer data in the Database, and all data is transmitted over HTTPS. Our Public API is built on Azure’s API Gateway, providing a robust system for issuing authentication credentials. We can limit account access and easily revoke access to accounts. This is useful when companies hire a solution provider to do work for them.
We are Type 1 Compliant:
Firewall to databases
Quarterly audits of firewall rules
Incident Management Plan/Response plan
Disaster Recovery/Business Continuity
Point-in-time Database backups
Change Management processes
All sites are HTTPS encrypted
Employee Security Training
DirectScale client data is not accessible to another client
Data transfer through the public API is monitored
Only authorized employees have access to production systems
Audit logs are reviewed quarterly
Traffic to applications is monitored for unusual traffic
Applications are protected using firewall, network policies, and access control policies
We regularly have vulnerability scans and employee training to ensure that we meet the best security practices.
We are Payment Card Industry Data Security Standard (PCI) compliant and partner with payment services, so we never need to store credit card data or transmit cardholder data through our systems. We use 3rd party hosted forms and only store tokenization data.
Rapid Provisioning is the process the Platform’s applications and hardware go through to launch a new client. We include data configurations for the multi-tenant applications and dedicated virtual hardware for the new client.
Provisioning involves the process of preparing and equipping an environment to allow it to provide services to users.
Software-Defined Infrastructure (SDI)
Software-defined infrastructure (SDI) is the automation of new client hardware resources using scripts. This process allows the configurations to be running within an hour instead of days.
All the provisioning scripts for configuring the system and setting up hardware are source controlled just like application code. Script changes are deployed to test and verify environments. Once verified, those changes are promoted to the production systems.
Disconnected Build and Deployment
Both code and SDI scripts are built and promoted across environments. This is important because it helps us guarantee that everything tested in pre-production environments matches the live release.
Extensible by Design
Each of our clients has particular requirements on the front end and back end. On the front end, many want their sites to be unique and to have personalized features. While on the backend, they want detailed commission plans and custom processes that happen during orders, shipping, rank advancements, etc.
We design for uniqueness, making all software extensible and customizable.
Customizations with Configuration
The next layer of handling extensibility is by extending functionality using developer knowledge. Developers can define the content and override behaviors. Examples include:
Your developers have access to make these code changes. We also have several preferred partners that you can work with to take care of custom code needs.
Configuration: Customer Sites
You can configure customer content to show at different times, ranks, statuses, types, languages, and by any KPIs or data points. This robust method of content configuration sets us apart from others. You can control content yourself without any help from us. Examples include:
Extensibility: Customer Sites
Customizations via Disco Core Platform
In Disco, you can hook into events asynchronously with webhooks that use an Event Bus. Use the Event Bus system to show alerts for when certain events occur on your Platform. For example, an alert that sends when a new enrollment occurs. This method allows for system notifications and won’t slow down system processing.
We also let you define your own code in C# with the Client Extension. We provide an Abstraction Layer, a NuGet package that has the interfaces available to you in the Disco code. With it, you can override various system functionality. Examples include placing orders or submitting an enrollment application.
You can add code that runs before and after the events using Hooks. An example would be when an order is placed to send out an email, log to a database table, or do validation before accepting an order. You can also override the event completely with custom work. An example would be when an order is placed, you could add bonus items to the order or apply a promotional discount. Then, call the base functionality for placing the order.