## 1. Introduction

# 1. Introduction

This section provides an overview of the current system capabilities, business context, and critical limitations relevant to order management and bulk order import functionality. The documentation is based exclusively on the provided system and business requirements, architectural constraints, and process descriptions.

## 1.1 Purpose

The purpose of this document is to define the requirements, constraints, and current system limitations regarding order creation, payment processing, and CSV/batch import functionality in the context of the DentalCare Pro order management system. This section is intended to support system migration, enhancement planning, and compliance verification by clearly stating the system's present boundaries and the business need for bulk order processing capabilities.  
[KB-146a6a29-932f-485d-96d6-6a92ee610336] [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f] [KB-155b5f4a-d232-4166-bb96-ba158f86ceb1] [KB-1603dccf-0e13-426d-a4c3-527af9e69c16] [KB-16181d30-2dd3-421e-bab0-939cd85255d2]

## 1.2 Scope

This document covers the following areas:

- The current process for order creation and its limitations (single-entry only, no batch/bulk import).
- The absence of CSV or file-based order import endpoints or UI elements.
- Constraints on payment processing (one transaction per order, no batch payment API).
- Notification service limitations (no bulk notification, individual API calls per notification).
- The business demand for bulk order import (CSV) to support operational efficiency for corporate customers.
- The impact of these limitations on system performance, user experience, and business operations.

## 1.3 Audience

This document is intended for:

- System architects and developers responsible for order management and payment modules.
- Business analysts and product owners evaluating enhancement requirements.
- Compliance and security officers verifying system boundaries and regulatory implications.
- Migration project teams planning for system upgrades or replacements.

## 1.4 System Overview

The current order management system is designed for single-order entry only. Orders can be created one at a time via the REST API or administrative interface. There is no capability for bulk or batch order creation, nor is there any endpoint or UI for uploading and processing order data from files such as CSV or Excel.  
[KB-146a6a29-932f-485d-96d6-6a92ee610336] [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f] [KB-16181d30-2dd3-421e-bab0-939cd85255d2]

Payment processing is similarly constrained: each order requires an individual payment API call, and no batch payment API exists. Notification services also operate on a per-order basis, with no support for bulk notification; each notification requires a separate API call.  
[KB-146a6a29-932f-485d-96d6-6a92ee610336] [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]

These limitations result in significant operational inefficiencies, especially for corporate customers who frequently request the ability to import large volumes of orders (100–10,000) via CSV files. The lack of bulk import and batch processing features is a high-severity constraint, impacting both system scalability and user productivity.  
[KB-155b5f4a-d232-4166-bb96-ba158f86ceb1] [KB-1603dccf-0e13-426d-a4c3-527af9e69c16]

## 1.5 Document Structure

The remainder of this document details:

- Functional and non-functional requirements for order and payment processing.
- Existing system limitations and their business/technical impact.
- Business justification for bulk order import features.
- Compliance and audit considerations related to order and payment workflows.

---

**References:**
- [KB-146a6a29-932f-485d-96d6-6a92ee610336]
- [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]
- [KB-155b5f4a-d232-4166-bb96-ba158f86ceb1]
- [KB-1603dccf-0e13-426d-a4c3-527af9e69c16]
- [KB-16181d30-2dd3-421e-bab0-939cd85255d2]
- [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]

## 2. Functional Requirements

## 2. Functional Requirements

### 2.1 Order Creation

| Requirement ID | Description                                                                                   | Priority |
|----------------|----------------------------------------------------------------------------------------------|----------|
| FR-001         | The system must allow creation of a single order by specifying customer information (name, email) and order details (item name, quantity, unit price). | P1       |
| FR-002         | The system must automatically calculate the total order amount as the sum of (quantity × unit price) for all order items. | P1       |
| FR-003         | The system must provide paginated retrieval of order lists, supporting parameters for skip (default 0) and limit (default 20). | P1       |
| FR-004         | The system must allow retrieval of a single order by order ID. If the order is not found, a 404 error must be returned. | P1       |
| FR-005         | The system must support updating the status of an order. Setting status to SHIPPED must trigger a shipping notification. | P1       |
| FR-006         | The system must allow cancellation of an order, which triggers refund processing via Payment Service and a cancellation notification via Notification Service. | P1       |
| FR-007         | The system must support receiving payment status updates from Payment Service via webhook and update order status accordingly. | P1       |

**Source:** [KB-0e0f1dd0-0f46-4d13-a092-e3cdc6fdd205], [KB-0972bd0e-7d3-4b2c-a364-813e023a3495], [KB-186b33d7-f985-455b-8117-0cd019912510]

---

### 2.2 Payment Processing

| Requirement ID | Description                                                                                   | Priority |
|----------------|----------------------------------------------------------------------------------------------|----------|
| PAY-001        | Payment processing must handle one transaction at a time. No batch payment API exists; each order requires an individual payment API call. | High     |
| PAY-002        | The maximum payment amount per transaction is 1,000,000 JPY. Payments exceeding this limit must be rejected with an error. | High     |
| PAY-003        | Payment Service API must be called with the payload: {"order_id": N, "amount": N.N, "currency": "JPY"}. | High     |
| PAY-004        | Payment Service API timeout is 30 seconds. On failure, the order status must revert to PENDING. | High     |

**Source:** [KB-01305cb3-d331-4b4b-ba02-69ada467b41d], [KB-10744011-e9ca-48b5-ac6d-4f9f3627b7e6], [KB-1718c2d8-b71b-4113-9906-a6d9765958ff], [KB-186b33d7-f985-455b-8117-0cd019912510]

---

### 2.3 Notification Processing

| Requirement ID | Description                                                                                   | Priority |
|----------------|----------------------------------------------------------------------------------------------|----------|
| NOTIF-001      | Notifications are sent individually per order. No bulk notification capability exists; each notification requires a separate API call. | Medium   |
| NOTIF-002      | Notification Service API rate limit is 10 notifications per second. For large imports (e.g., 10,000 orders), notification processing will take at least 1,000 seconds (~17 minutes). | Medium   |
| NOTIF-003      | Notification Service must be called with one notification per request. | Medium   |
| NOTIF-004      | Notification Service API timeout is 10 seconds. | Medium   |

**Source:** [KB-01305cb3-d331-4b4b-ba02-69ada467b41d], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a], [KB-06c5403a-d177-4525-b247-1d7ae37a86b8], [KB-1718c2d8-b71b-4113-9906-a6d9765958ff]

---

### 2.4 System Limitations and Constraints

| Limitation ID | Description                                                                                   | Impact Area       | Severity |
|---------------|----------------------------------------------------------------------------------------------|-------------------|----------|
| LIM-001       | Order creation is single-entry only. No bulk or batch order creation capability exists. Orders can only be created one at a time via the REST API. | Order Service     | High     |
| LIM-002       | No CSV/file-based order import functionality. There is no endpoint or mechanism to upload and process order data from files (CSV, Excel, etc.). | Order Service     | High     |
| LIM-003       | Payment processing handles one transaction at a time. No batch payment API exists. Each order requires an individual payment API call. | Payment Service   | High     |
| LIM-004       | Notifications are sent individually per order. No bulk notification capability exists. Each notification requires a separate API call. | Notification Service | Medium  |
| LIM-005       | Cross-service calls are sequential. Order creation flow (Order → Payment → Notification) executes sequentially. No parallel processing of payment and notification. | All Services      | Medium   |
| LIM-006       | No progress tracking for batch operations. The system has no mechanism to track progress of multi-item operations because no batch operations exist. | All Services      | Medium   |

**Source:** [KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a], [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c], [KB-0f930ddc-1f3a-4014-a015-49fe1808f8d8]

---

### 2.5 Data Model and API Contracts

| Table/Field      | Data Type    | Constraint/Validation                 | Notes                                 |
|------------------|-------------|---------------------------------------|---------------------------------------|
| order_id         | INTEGER     | PRIMARY KEY, UNIQUE                   | No batch_id, no bulk_import_group     |
| amount           | FLOAT       | >= 100, <= 1,000,000                  | Per transaction                       |
| currency         | VARCHAR     | Default "JPY"                         |                                       |
| status           | ENUM        | PaymentStatus                         |                                       |
| payment_method   | VARCHAR     | "credit_card"                         |                                       |
| transaction_id   | VARCHAR     | UNIQUE, UUID                          |                                       |

**Source:** [KB-11739ab0-b209-41e4-b73e-7d7e0c433b2], [KB-0f930ddc-1f3a-4014-a015-49fe1808f8d8]

---

### 2.6 Business Requirements for CSV Import (Not Implemented)

Multiple business requirements reference the need for CSV/batch import to support operational efficiency for corporate customers, specifically for importing 100–10,000 orders at once. However, the current system does NOT implement any CSV upload, batch import, or bulk creation functionality.

**Source:** [KB-155b5f4a-d232-4166-bb96-ba158f86ceb1], [KB-1603dccf-0e13-426c-a4c3-527af9e69c16], [KB-161f44bf-9450-491f-b894-1fd70c185060]

---

### 2.7 Summary of Functional Gaps

- No bulk order creation or CSV import capability.
- No batch payment or notification processing.
- No progress tracking for batch operations.
- All order, payment, and notification actions are single-entry and sequential.

**Source:** [KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f], [KB-0f930ddc-1f3a-4014-a015-49fe1808f8d8]

---

**End of Section 2. Functional Requirements**

## 3. Non-Functional Requirements

# 3. Non-Functional Requirements

## 3.1 Performance

### 3.1.1 API and System Response Time

| Metric                      | Target                    | Measurement              |
|-----------------------------|---------------------------|--------------------------|
| API response time (p50)     | < 200ms                   | Application metrics      |
| API response time (p95)     | < 500ms                   | Application metrics      |
| API response time (p99)     | < 1,000ms                 | Application metrics      |
| Page load time (initial)    | < 2 seconds               | Lighthouse measurement   |
| Page load time (subsequent) | < 1 second                | Client-side metrics      |
| System availability         | 99.9% (8.77 hrs/year max) | Uptime monitoring        |
| Concurrent users            | 500+ simultaneous         | Load testing             |
| Database query time (avg)   | < 100ms                   | RDS Performance Insights |
| API throughput              | > 1,000 req/min           | Load testing             |

[KB-0d9e59c7-0414-46c2-b302-2f4cbc1e9e88]

### 3.1.2 Batch and Bulk Operations

- **Bulk order creation is NOT supported.** All order creation, payment, and notification operations are single-entry and must be performed one at a time via the REST API. There is no CSV or file-based import capability. [KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]
- **Notification Service:** No bulk notification API. Each notification is sent individually, with a rate limit of 10 notifications per second. Sending 10,000 notifications requires at least 1,000 seconds (~17 minutes). [KB-06c5403a-d177-4525-b247-1d7ae37a86b8], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]
- **Payment Service:** No batch payment API. Each order requires an individual payment API call. Maximum amount per transaction is 1,000,000 JPY. [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c], [KB-10744011-e9ca-48b5-ac6d-4f9f-3627b7e6]

### 3.1.3 Sequential Processing

- All cross-service operations (Order → Payment → Notification) are executed sequentially, not in parallel. This impacts overall throughput and latency for high-volume operations. [KB-033639ab-c6f8-4f72-a373-bf76d05dd6cf], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f], [KB-150eb89c-77b0-415b-a547-3ed0502eec24]

## 3.2 Security

### 3.2.1 Authentication and Authorization

| Feature                 | Implementation                             | Priority   |
|-------------------------|--------------------------------------------|------------|
| Authentication          | OAuth 2.0 Resource Server + Azure AD       | Critical   |
| Authorization           | Method-level @PreAuthorize with SpEL       | Critical   |
| CSRF Protection         | SameSite cookies + CSRF tokens             | High       |
| CORS Policy             | Whitelist-based origin validation          | High       |
| Content Security Policy | Strict CSP headers                         | High       |
| Rate Limiting           | Bucket4j with Redis backend                | Medium     |
| Input Validation        | Bean Validation + custom validators        | Critical   |
| Output Encoding         | OWASP Java Encoder                         | Critical   |
| Session Management      | Stateless (JWT) with Redis token blacklist | Critical   |
| Dependency Scanning     | OWASP Dependency-Check in CI/CD            | High       |

[KB-0910e88e-c115-4412-a137-d96b5c1a2082]

- **JWT Security:** RS256 algorithm, 15 min access token lifetime, 8 hour refresh token lifetime (sliding window), CORS whitelist, strict SameSite/CSRF, security headers enforced. [KB-06cbdf57-f5b7-42c6-9d15-4119f65cd34e]

### 3.2.2 Error Handling

- **CRITICAL SECURITY RULE:** Error responses in production must NEVER contain PHI, stack traces, SQL queries, internal file paths, server names, or framework version information. Violations are treated as security incidents. [KB-10300d8a-a98a-4726-9be3-3957c2fe7bf4], [KB-140ca7f3-3348-4419-b06b-89561882a35e]

### 3.2.3 Data Security

| Control                          | Implementation                        | HIPAA Reference    |
|----------------------------------|---------------------------------------|--------------------|
| Encryption at rest (database)    | AWS RDS encryption (AES-256)          | §164.312(a)(2)(iv) |
| Encryption at rest (files)       | S3 SSE-KMS (AES-256)                  | §164.312(a)(2)(iv) |
| Encryption at rest (field-level) | JPA AttributeConverter + AES-256-GCM  | §164.312(a)(2)(iv) |
| Encryption in transit            | TLS 1.3 (all communications)          | §164.312(e)(1)     |
| Key Management                   | AWS KMS (customer-managed CMKs)       | §164.312(a)(2)(iv) |
| Data masking (dev/test)          | Faker-based synthetic data pipeline   | §164.514(b)(2)     |

[KB-116f84fb-2eec-4493-9762-414a92624981]

- **PHI in API responses:** All responses containing PHI must include `Cache-Control: no-store` and `Pragma: no-cache` to prevent client-side caching. [KB-16e42083-f456-49b3-b894-1fd70c185060]

### 3.2.4 Audit Logging and Retention

| Log Category            | Hot Storage (Searchable)   | Warm Storage (Archived)   | Cold Storage (Compliance)   | Total Retention   |
|-------------------------|----------------------------|---------------------------|-----------------------------|-------------------|
| Authentication events   | 90 days                    | 1 year                    | 6 years                     | 7 years           |
| PHI access events       | 90 days                    | 1 year                    | 6 years                     | 7 years           |
| PHI modification events | 90 days                    | 2 years                   | 6 years                     | 8 years           |
| Administrative events   | 90 days                    | 1 year                    | 6 years                     | 7 years           |
| Security events         | 180 days                   | 2 years                   | 6 years                     | 8 years           |

[KB-059dda76-1a60-4539-a60b-e504ba4e11ea]

## 3.3 Reliability

### 3.3.1 System Availability

- **Target system availability:** 99.9% (maximum 8.77 hours downtime per year). [KB-0d9e59c7-0414-46c2-b302-2f4cbc1e9e88]

### 3.3.2 Failure Handling

- **No retry or circuit breaker mechanisms** are implemented for cross-service API calls. Failures are logged but not retried. [KB-01305cb3-d331-4b4b-ba02-69ada467b41d], [KB-033639ab-c6f8-4f72-a373-bf76d05dd6cf], [KB-150eb89c-77b0-415b-a547-3ed0502eec24]
- **Batch error handling is not supported.** If a failure occurs during a batch operation (not currently supported), there is no mechanism to continue processing remaining items. [KB-04a84995-0820-4319-c1582821058a], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]

### 3.3.3 Data Integrity

- All database operations must enforce referential integrity, uniqueness, and validation constraints as defined in the schema. [KB-0368630b-7eb5-445e-aa3b-de044dd2e57a], [KB-17241d34-125d-4e6f-8e0a-53ebb68f3584]

### 3.3.4 Incident Response

- Incident response plan is documented and tested. Incident reporting is available via JIRA Security Queue and hotline. Post-incident review and breach notification procedures are in place. [KB-052c37cd-e1b9-4ebf-a934-e4cff20e9718]

## 3.4 Maintainability

- **Versioning:** Only major versions are included in the API URL (e.g., /v1/patients). Minor and patch changes must be backward-compatible. Deprecation notice is required at least 6 months before version retirement. Maximum of 2 active major versions at any time. [KB-10300d8a-a98a-4726-9be3-3957c2fe7bf4], [KB-140ca7f3-3348-4419-b06b-89561882a35e]

## 3.5 System Limitations

| ID      | Limitation                                                                                      | Impact Area          | Severity   |
|---------|-------------------------------------------------------------------------------------------------|----------------------|------------|
| LIM-001 | Order creation is single-entry only. No bulk or batch order creation capability exists.         | Order Service        | High       |
| LIM-002 | No CSV/file-based order import functionality.                                                   | Order Service        | High       |
| LIM-003 | Payment processing handles one transaction at a time. No batch payment API exists.              | Payment Service      | High       |
| LIM-004 | Notifications are sent individually per order. No bulk notification capability exists.           | Notification Service | Medium     |
| LIM-005 | Cross-service calls are sequential. No parallel processing of payment and notification.         | All Services         | Medium     |
| LIM-006 | No progress tracking for batch operations. No mechanism to track progress of multi-item ops.    | All Services         | Medium     |

[KB-146a6a29-932f-485d-96d6-6a92ee610336]

---

**Note:** Any features requiring bulk import, batch processing, or parallel execution will require significant architectural changes beyond the current system’s capabilities.

---

If additional non-functional requirements are needed (e.g., usability, accessibility, etc.) and are not present in the provided context, please note:

[GAP: Missing data for 3. Non-Functional Requirements]

## 4. Architecture

## 4. Architecture

### 4.1 Overview

The current system architecture is based on a microservices model, with distinct services for order management, payment processing, and notification delivery. The frontend is implemented as a React single-page application (SPA) that interacts with three backend microservices via REST APIs. All inter-service communication is synchronous REST over HTTP, with no message broker or asynchronous event bus present. Each service is deployed as a Spring Boot application, typically running in an ECS Fargate cluster. Data storage utilizes PostgreSQL, with audit logs managed in both PostgreSQL and CloudWatch/Elasticsearch for analysis. Security and compliance controls are implemented according to HIPAA requirements, including encryption at rest and in transit, audit logging, and strict error handling policies.

#### System Diagram (Conceptual)

```
┌───────────────────────────────┐
│      React Frontend (SPA)     │
└─────────────▲─────────────────┘
              │
              ▼
┌─────────────┼───────────────────────────────┐
│          API Gateway / Load Balancer        │
└─────────────┼───────────────────────────────┘
              │
      ┌───────┼───────────────┬───────────────┐
      │       │               │               │
      ▼       ▼               ▼               ▼
┌────────┐ ┌────────────┐ ┌──────────────┐ ┌───────────────┐
│ Order  │ │ Payment    │ │ Notification │ │ Audit Service │
│ Service│ │ Service    │ │ Service      │ │ (Spring Boot) │
└────────┘ └────────────┘ └──────────────┘ └───────────────┘
      │       │               │               │
      ▼       ▼               ▼               ▼
┌───────────────────────────────────────────────────────────┐
│                PostgreSQL / CloudWatch / Elasticsearch    │
└───────────────────────────────────────────────────────────┘
```
[KB-050d0be4-11bc-4945-80e4-1f59d3187e45], [KB-0e90d327-2678-405f-b35a-294b5435dc66], [KB-1a54c453-d6ee-488f-bbdc-311c467a9661], [KB-068a18d0-0c02-4fbf-a287-f0ef9a4d2477]

---

### 4.2 Building Blocks

#### Backend Services

| Service         | Technology       | Deployment        | Key Features                                  |
|-----------------|-----------------|-------------------|-----------------------------------------------|
| Order Service   | Spring Boot      | ECS Fargate       | Single order creation, REST API, no batch     |
| Payment Service | Spring Boot      | ECS Fargate       | Single payment per order, REST API, no batch  |
| Notification    | Spring Boot      | ECS Fargate       | Single notification per order, REST API, rate limit 10/sec |
| Audit Service   | Spring Boot      | ECS Fargate       | Comprehensive audit logging, HIPAA compliance |

[KB-0e90d327-2678-405f-b35a-294b5435dc66], [KB-00a1545e-dddf-4456-ac12-082fe756ab9e], [KB-068a18d0-0c02-4fbf-a287-f0ef9a4d2477]

#### Data Storage

| Component           | Technology         | Purpose                       |
|---------------------|-------------------|-------------------------------|
| Main Database       | PostgreSQL 16     | Transactional data storage    |
| Audit Log Storage   | PostgreSQL, CloudWatch, Elasticsearch | Audit log retention and analysis |

[KB-1a54c453-d6ee-488f-bbdc-311c467a9661], [KB-17a58f06-2387-412d-bf37-2f4d751e1d7e]

---

### 4.3 Interface Architecture

#### REST API Contracts

- All services expose REST endpoints for CRUD operations.
- Order creation, payment processing, and notification sending are strictly single-entry per API call.
- No batch or bulk endpoints exist; each order, payment, and notification must be handled individually.
- Payment Service: POST /api/v1/payments (single payment per order, max 1,000,000 JPY)
- Notification Service: POST /api/v1/notifications/email (one email per request, rate limit 10/sec)
- Order Service: POST /api/v1/orders (single order creation only)
- No CSV upload, batch import, or drag-and-drop UI is available for orders.

| Service         | Endpoint Example                         | Batch Capability | Rate Limit / Constraint           |
|-----------------|------------------------------------------|------------------|-----------------------------------|
| Order Service   | POST /api/v1/orders                      | × (None)         | Single order per call             |
| Payment Service | POST /api/v1/payments                    | × (None)         | Single payment per call, max 1M JPY |
| Notification    | POST /api/v1/notifications/email         | × (None)         | 10/sec, single notification per call |

[KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c], [KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-04a84995-0820-4319-9d26-c1582821058a], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f], [KB-1718c2d8-b71b-4113-9906-a6d9765958ff], [KB-186b33d7-f985-455b-8117-0cd019912510], [KB-01305cb3-d331-4b4b-ba02-69ada467b41d], [KB-06c5403a-d177-4525-b247-1d7ae37a86b8]

---

### 4.4 Architectural Constraints

| Constraint ID | Description                                                                                   | Impact Area         | Severity   |
|---------------|----------------------------------------------------------------------------------------------|---------------------|------------|
| LIM-001       | Order creation is single-entry only. No bulk or batch order creation capability exists.       | Order Service       | High       |
| LIM-002       | No CSV/file-based order import functionality. No endpoint or mechanism to upload/process files| Order Service       | High       |
| LIM-003       | Payment processing handles one transaction at a time. No batch payment API exists.            | Payment Service     | High       |
| LIM-004       | Notifications are sent individually per order. No bulk notification capability exists.        | Notification Service| Medium     |
| LIM-005       | Cross-service calls are sequential. No parallel processing of payment and notification.       | All Services        | Medium     |
| LIM-006       | No progress tracking for batch operations. No mechanism to track progress of multi-item ops. | All Services        | Medium     |

[KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a], [KB-04a84995-0820-4319-9d26-c1582821058a], [KB-150eb89c-77b0-415b-a547-3ed0502eec24]

- **No batch import:** All bulk order creation, payment, and notification features are not supported. CSV import is not available.
- **Sequential processing:** Order creation, payment, and notification are executed sequentially, resulting in slow processing for large volumes (e.g., 10,000 orders require 10,000 API calls and >17 minutes for notifications alone).
- **No retry/circuit breaker:** Failures are logged but not retried; error handling is limited, and there is no fallback or batch retry mechanism.
- **Schema limitations:** Orders table lacks batch_id, csv_source, bulk_import_group fields; cannot track batch membership or source file for orders.

[KB-02bc6ee3-521e-4ebf-b934-b7e08bd16081], [KB-0f930ddc-1f3a-4014-a015-49fe1808f8d8], [KB-11739ab0-b209-41e4-b73e-7d7e0c4338b2]

---

### 4.5 Security Architecture

- **Authentication:** OAuth 2.0 Resource Server with Azure AD integration.
- **Authorization:** Method-level @PreAuthorize with SpEL; session management is stateless (JWT) with Redis token blacklist.
- **Encryption:** AES-256 for database and file storage, TLS 1.3 for all communications.
- **Audit Logging:** Comprehensive audit controls, including PHI access events, stored in PostgreSQL and CloudWatch/Elasticsearch.
- **Error Handling:** Production error responses never expose PHI, stack traces, SQL queries, internal paths, server names, or framework version info.

| Feature                 | Implementation                             | Priority   |
|-------------------------|--------------------------------------------|------------|
| Authentication          | OAuth 2.0 Resource Server + Azure AD       | Critical   |
| Authorization           | Method-level @PreAuthorize with SpEL       | Critical   |
| CSRF Protection         | SameSite cookies + CSRF tokens             | High       |
| CORS Policy             | Whitelist-based origin validation          | High       |
| Content Security Policy | Strict CSP headers                         | High       |
| Rate Limiting           | Bucket4j with Redis backend                | Medium     |
| Input Validation        | Bean Validation + custom validators        | Critical   |
| Output Encoding         | OWASP Java Encoder                         | Critical   |
| Session Management      | Stateless (JWT) with Redis token blacklist | Critical   |
| Dependency Scanning     | OWASP Dependency-Check in CI/CD            | High       |

[KB-0910e88e-c115-4412-a137-d96b5c1a2082], [KB-0667f620-e2f7-4030-8e28-f56315efb7d0], [KB-06cbdf57-f5b7-42c6-9d15-4119f65cd34e], [KB-116f84fb-2eec-4493-9762-414a92624981], [KB-10300d8a-a98a-4726-9be3-3957c2fe7bf4], [KB-140ca7f3-cf60-4021-9822-34a48d940c94]

---

### 4.6 Performance and Scalability

- **API response times:** Target <200ms (p50), <500ms (p95), <1,000ms (p99).
- **Page load times:** Initial <2s, subsequent <1s.
- **System availability:** 99.9% uptime.
- **Concurrent users:** 500+ supported.
- **Batch limitations:** Large-scale operations (e.g., 10,000 orders) are extremely slow due to sequential processing and lack of batch APIs.

| Metric                      | Target                    | Measurement              |
|-----------------------------|---------------------------|--------------------------|
| API response time (p50)     | < 200ms                   | Application metrics      |
| API response time (p95)     | < 500ms                   | Application metrics      |
| API response time (p99)     | < 1,000ms                 | Application metrics      |
| Page load time (initial)    | < 2 seconds               | Lighthouse measurement   |
| Page load time (subsequent) | < 1 second                | Client-side metrics      |
| System availability         | 99.9% (8.77 hrs/year max) | Uptime monitoring        |
| Concurrent users            | 500+ simultaneous         | Load testing             |

[KB-0d9e59c7-0414-46c2-b302-2f4cbc1e9e88], [KB-150eb89c-77b0-415b-a547-3ed0502eec24]

---

### 4.7 Compliance

- **HIPAA:** All PHI responses include Cache-Control: no-store and Pragma: no-cache.
- **Audit trail:** Comprehensive, continuous, and retained per regulatory requirements.
- **Encryption:** Database, file, and field-level encryption are implemented.
- **Incident response:** Security incident procedures are documented and tested.

[KB-16e42083-f456-49a3-959d-419cdb9fc31d], [KB-116f84fb-2eec-4493-9762-414a92624981], [KB-052c37cd-e1b9-4ebf-8d87-e3a1d85fc99]

---

### 4.8 Architectural Weaknesses and Risks

- No batch import or bulk processing for orders, payments, or notifications.
- Sequential processing causes significant latency for large volumes.
- No retry or circuit breaker for cross-service calls; failures are not retried.
- Schema lacks fields for batch tracking, import source, or group association.
- No progress tracking for batch operations.

[KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f], [KB-0f930ddc-1f3a-4014-a015-49fe1808f8d8], [KB-04a84995-0820-4319-9d26-c1582821058a], [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c], [KB-146a6a29-932f-485d-96d6-6a92ee610336]

---

### 4.9 Summary

The architecture is robust for single-order processing and meets stringent security and compliance requirements. However, it is fundamentally limited in batch and bulk processing capabilities. Any requirements for CSV import, batch order creation, batch payment, or bulk notification will require significant architectural changes across all affected services.

---

*End of Section 4. Architecture*