Disaster recovery & BI

A word about Sveltekit adapters.

21RISK is built with Sveltekit , a modern application framework that makes a clear abstraction so developers don’t have to think about the target deployment. This makes it very flexible to change where the application code is deployed. As of june 2023, Sveltekit supports the following deployment targets:

Adapter Target
@sveltejs/adapter-cloudflare Cloudflare Pages
@sveltejs/adapter-cloudflare -workers Cloudflare Workers
@sveltejs/adpater-netlify Netlify
@sveltejs/adapter-node Node servers
@sveltejs/adapter-static Static site generation
@sveltejs/adapter-vercel Vercel (The adapter 21RISK is currently using, since may 2023.)

Failover strategy

To avoid any downtime we utilise a comprehensive failover strategy on all avenues of our application. This helps ensure that any regional or local incidents do not impact performance and result in downtime.

  • Vercel uses AWS Global Accelerator and Anycast network to automatically reroute traffic to another region in case of regional failure.
  • Edge functions and Edge Middleware switch to another region automatically using Cloudflare's automatic failover feature
  • Mongodb Cross cloud failover - ensures that data is replicated to multiple regions.
  • Mongodb Multi cloud provider backups - We do periodic backups to multiple different cloud providers to ensure that even in the event of a total loss of the cloud provider AWS we still have ensured our data.

Disaster Recovery Plan

A Disaster Recovery Plan (DRP) is essential for businesses of all sizes, including your small development team. The purpose of a DRP is to ensure that your team can respond to a disaster or other emergency that affects information systems and minimize the effect on the operation of the business.

Risk Assessment

An ordered list of the most critical incidents to affect our system: This list provides the foundation for the steps we take in order to minimize the impact if they should occur.

  • Regional at MongoDB Atlas -> Failover strategy
  • Complete Outage at MongoDB Atlas -> Move to alternate processing site
  • Outage at Doppler -> Move to alternate processing site
  • Outage at WorkOS -> Move to alternate processing site
  • Regional outage at Vercel -> Failover strategy
  • Complete outage at Vercel -> Move to alternate processing site
  • Outage at AWS -> Move to alternate processing site
  • Outage at Github -> Move to alternate processing site

Identify Critical Assets

Identify which data, hardware, and software are critical to business operations. Prioritize their recovery in the event of a disaster.

  • MongoDB Atlas
  • WorkOS
  • UploadCare
  • Github
  • NPM
  • Doppler
  • AWS
  • Power BI

Backup and Restore Procedures

Service Backup policy Recovery Point Objective
MongoDB Atlas We have an extensive backup policy, described in this document. It’s cross-region. The backups are full, nothing is left out. full
Uploadcare We have AWS-bucket backups of all files in UploadCare configured full
Github All changes to the code is in version control, running on full
Power BI All Power BI files are backed up in Google Drive full

Disaster Response

Step 1 Better stack will automatically contact Alex and Andreas, when downtime in the system is identified.

Step 2 Depending on the severity of the plan, a physical meetup is arranged with the priority to protect/verify all backups are in place.

Recovery Procedures

Document the steps necessary to recover each of your critical assets. This should include steps to restore data from backups, how to ensure that restored systems are secure, and how to validate that systems are functioning correctly after recovery.

Service Steps to validate Steps to recover
MongoDB Atlas Navigate to, login and verify backups are there. Create a new target cluster, and restore the backup.
Uploadcare Log into the AWS portal, and find the backup bucket “21risk-backup-static-files” Download files and upload to alternate provider
SourceCode Connect to the 21RISK/eddystone repository and download the codebase. (Alternatively use Github codespaces, where the code is also present).

Alternate Processing Sites: For critical systems

In the event of a disaster at one of our current service providers, we would migrate the following services to the alternative providers to ensure functionality. 28 Please note that the alternate providers are not actively used currently.

Service Current Alernative
Database MongoDB Atlas Self-hosted on Digital Ocean / Heroku
Hosting Vercel Heroku
Data storage Uploadcare Cloudinary
Authentication WorkOS Auth0
Version control Github Gitlab
Secrets management Doppler 1Password