# Production vs. Disaster Recovery vs. Testing Environment

#### Overview

When designing a platform architecture for **ONEWEB**, it is essential to define **separate environments** for different stages of the application lifecycle. Each environment serves a specific purpose and is designed with different priorities in terms of stability, availability, and risk.

A typical enterprise setup includes:

* **Testing Environment**
* **Production Environment**
* **Disaster Recovery Environment**

This separation ensures system reliability, controlled change management, and business continuity.

***

#### Testing Environment

The **Testing Environment** is used to validate application functionality before it is released to end users.

This environment supports activities such as:

* Functional testing
* Integration testing
* User acceptance testing (UAT)

When designing a Testing Environment, consider:

* Number of testers and stakeholders involved
* External systems that need to be integrated
* Volume and type of test data required

The Testing Environment is typically less restrictive than Production and allows frequent changes and iterations without impacting live users.

***

#### Production Environment

The **Production Environment** is where ONEWEB applications are made available to end users and business operations.

This environment is the most critical, as it directly impacts business continuity and service quality. Architectural decisions for Production must prioritize stability, performance, and availability.

Key considerations include:

* **Application characteristics**\
  Real‑time behavior, system integrations, data volume, and 24/7 operation requirements
* **Business criticality**\
  Impact on users and operations if the system becomes unavailable
* **User scale**\
  Number of active users and named users
* **Transaction volume**\
  Expected number of transactions over defined periods
* **Accepted downtime**\
  Tolerable frequency and duration of service interruptions

Production environments commonly use **High Availability** or **Cloud Architecture** patterns to meet reliability and scalability requirements.

***

#### Disaster Recovery Environment

The **Disaster Recovery (DR) Environment** acts as a standby environment to ensure business continuity in case the Production Environment becomes unavailable.

Unlike Production, the DR Environment is not intended for continuous operation. It is activated only during major incidents or system failures.

Key design considerations include:

* **Recovery Point Objective (RPO)**\
  Maximum acceptable data loss when switching to the DR Environment
* **Recovery Time Objective (RTO)**\
  Maximum acceptable time required to restore services
* **Capacity planning**\
  Percentage of Production capacity required during disaster scenarios

A well‑designed DR strategy minimizes downtime and data loss while balancing infrastructure cost.

***

#### Relationship Between Environments

From a platform architecture perspective:

* **Testing** focuses on validation and change readiness
* **Production** focuses on availability, performance, and reliability
* **Disaster Recovery** focuses on resilience and continuity

Each environment may use different deployment models (Standalone, High Availability, or Cloud), but all environments should follow consistent architectural principles to ensure predictable behavior across the lifecycle.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.onewebstack.com/oneweb-platform-th/overview/platform-architecture/production-vs.-disaster-recovery-vs.-testing-environment.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
