## 1. Introduction

# 1. Introduction

This section provides an overview of the current system architecture, business requirements, and operational constraints relevant to the Order Management and CSV Import functionality for the EC site. The documentation is structured in accordance with ISO-29148 requirements and is based strictly on the provided knowledge base context.

## 1.1 Purpose

The purpose of this document is to define the requirements, limitations, and business rationale for the Order Management system, specifically focusing on bulk order creation and CSV import capabilities. The aim is to support operational efficiency for corporate clients who frequently request the ability to import large volumes of orders (100–10,000 orders) via CSV files. This functionality is intended to address the inefficiencies of the current system, which only allows single-order creation via REST API or the web management interface. The business case for this enhancement is to significantly improve operational efficiency and support the business processes of corporate customers. [KB-155b5f4a-d232-4166-bb96-ba158f86ceb1], [KB-1603dccf-0e13-426d-a4c3-527af9e69c16], [KB-161f44bf-9450-491f-b894-1fd70c185060]

## 1.2 Scope

This document covers the following areas:

- Functional requirements for order creation, listing, and CSV import.
- System limitations regarding bulk operations, batch processing, and API constraints.
- Business rules and operational impacts for corporate clients.
- Architectural context for the EC site, including REST API integration and frontend/backend interactions.

## 1.3 System Overview

The EC site Order Management system provides a web management interface (React SPA) connected to three backend microservices via REST API. The current architecture supports only single-order creation, with no bulk or batch order creation capabilities. There is no CSV/file-based order import functionality, and each order must be created individually. [KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f], [KB-16181d30-2dd3-421e-bab0-939cd85255d2], [KB-050d0be4-11bc-4945-80e4-1f59d3187e45]

## 1.4 Business Rationale

Corporate customers have repeatedly requested the ability to import large volumes of orders via CSV files to streamline their business processes. The current system's single-entry limitation is a significant operational bottleneck. Implementing bulk CSV import functionality is expected to greatly enhance operational efficiency and support the scalability needs of corporate clients. [KB-155b5f4a-d232-4166-bb96-ba158f86ceb1], [KB-1603dccf-0e13-426d-a4c3-527af9e69c16], [KB-161f44bf-9450-491f-b894-1fd70c185060]

## 1.5 Architectural Constraints

The following architectural constraints define the boundaries of the current system:

| 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. No endpoint or mechanism to upload and process order data.    | 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. 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 operations.         | All Services         | Medium     |

[KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]

## 1.6 Document Structure

This document is organized to provide:

- Detailed functional and non-functional requirements
- System constraints and architectural limitations
- Business process context and rationale
- Reference to relevant tables and system artifacts

All content is strictly grounded in the provided knowledge base context and adheres to ISO-29148 documentation standards.

## 2. Functional Requirements

## 2. Functional Requirements

### 2.1 Order Creation

| ID     | Requirement                                                                                                    | 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 from the sum of (quantity × unit price) for each item. | P1       |
| FR-003 | The system must support paginated retrieval of order lists using skip and limit parameters.                    | P1       |

**Reference:** [KB-0e0f1dd0-0f46-4d13-a092-e3cdc6fdd205]

### 2.2 Order Management Interface

- The interface displays a warning banner indicating CSV import is not available.
- The CSV Import button is disabled and labeled “CSV Import (Not Implemented)”.
- Users can search orders by customer name/email (client-side filter).
- Status filter dropdown and sortable order table are provided.
- Single order creation form is available.
- Orders can be cancelled with a confirmation dialog.

**Reference:** [KB-16181d30-2dd3-421e-bab0-939cd85255d2]

### 2.3 Order Detail Retrieval

- Order detail view fetches data from all three services in parallel:
    1. Order Service: GET /api/v1/orders/{id}
    2. Payment Service: GET /api/v1/payments/order/{id}
    3. Notification Service: GET /api/v1/notifications/order/{id}
- Displays order information, items, payment card, and notification history.

**Reference:** [KB-16181d30-2dd3-421e-bab0-939cd85255d2]

### 2.4 Order Status Management

| Method      | Endpoint                              | Description                                 |
|-------------|---------------------------------------|---------------------------------------------|
| GET         | /api/v1/orders/                       | List orders (paginated; skip, limit)        |
| GET         | /api/v1/orders/{order_id}             | Retrieve single order with items            |
| PUT         | /api/v1/orders/{order_id}/status      | Update order status; SHIPPED triggers notification |
| DELETE      | /api/v1/orders/{order_id}             | Cancel order; triggers refund and cancellation email |
| POST        | /api/v1/orders/{order_id}/webhook     | Receive payment status updates from Payment Service |

**Reference:** [KB-0972bd0e-7d3f-4b2c-a364-813e023a3495]

### 2.5 Payment Processing

- Payment processing is performed one transaction at a time. No batch payment API exists.
- Each order requires an individual payment API call.
- Payment Service endpoint: POST /api/v1/payments
- Maximum amount per transaction: 1,000,000 JPY
- Minimum amount per transaction: 100 JPY
- Payment processing is triggered by order creation.
- If payment fails, order status reverts to PENDING.

**Reference:** [KB-186b33d7-f985-455b-8117-0cd019912510], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a], [KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-11739ab0-b209-41e4-b73e-7d7e0c433b8b], [KB-10744011-e9ca-48b5-ac6d-4f9f3627b7e6]

### 2.6 Notification Processing

- Notifications are sent individually per order. No bulk notification capability exists.
- Each notification requires a separate API call.
- Notification Service endpoint: POST /api/v1/notifications/email (one email per request)
- Rate limit: 10 notifications per second.

**Reference:** [KB-05a9aed3-6a71-4c74-ac19-6bfec293268b], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a], [KB-146a6a29-932f-485d-96d6-6a92ee610336]

### 2.7 System Limitations

| ID      | Limitation                                                                                                         | 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     |

**Reference:** [KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]

### 2.8 CSV Import Functional Requirement (Not Implemented)

| ID          | Requirement                              | Description                                                         | Priority | Impacted Service | Acceptance Criteria                                  |
|-------------|------------------------------------------|---------------------------------------------------------------------|----------|------------------|------------------------------------------------------|
| FR-BULK-001 | CSV file upload                          | User can upload CSV file. Max file size: 50MB. Supported encoding: UTF-8, Shift_JIS. | P1       | Order Service    | [GAP: Missing data for 2. Functional Requirements]   |

**Reference:** [KB-063a89e7-bb79-4435-993b-95ec7b9a9e4e]

---

**Note:** Bulk order import, batch payment, and batch notification features are not supported in the current system. All operations must be performed individually per order. CSV import functionality is not implemented and is explicitly disabled in the UI. Progress tracking for batch operations is not available.  
**References:** [KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-16181d30-2dd3-421e-bab0-939cd85255d2], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a], [KB-063a89e7-bb79-4435-993b-95ec7b9a9e4e]

## 3. Non-Functional Requirements

# 3. Non-Functional Requirements

This section specifies the non-functional requirements for the system, including performance, security, reliability, and system limitations, as required by ISO-29148. All requirements are derived strictly from the provided context.

---

## 3.1 Performance Requirements

### 3.1.1 API and System Performance

| 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              | [GAP: Missing data for throughput] | [GAP: Missing data]     |

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

### 3.1.2 Bulk and Batch Processing Performance

- **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. [KB-146a6a29-932f-485d-96d6-6a92ee610336]
- **No CSV/file-based order import functionality.** There is no endpoint or mechanism to upload and process order data from files (CSV, Excel, etc.). [KB-146a6a29-932f-485d-96d6-6a92ee610336]
- **Payment processing handles one transaction at a time.** No batch payment API exists. Each order requires an individual payment API call. [KB-146a6a29-932f-485d-96d6-6a92ee610336]
- **Notifications are sent individually per order.** No bulk notification capability exists. Each notification requires a separate API call. [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]
- **Cross-service calls are sequential.** Order creation flow (Order → Payment → Notification) executes sequentially. No parallel processing of payment and notification. [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]
- **No progress tracking for batch operations.** The system has no mechanism to track progress of multi-item operations because no batch operations exist. [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]

#### Example: Large Order Processing

- Processing 10,000 orders requires 10,000 API calls (one per order). This results in extremely low throughput for high-volume operations. [KB-150eb89c-77b0-415b-a547-3ed0502eec24]
- Payment and notification services are also invoked per order, further increasing total processing time for bulk operations. [KB-150eb89c-77b0-415b-a547-3ed0502eec24]
- Notification service rate limit: 10 notifications/second. Sending 10,000 notifications requires a minimum of 1,000 seconds (~17 minutes). [KB-06c5403a-d177-4525-b247-1d7ae37a86b8]

---

## 3.2 Security Requirements

### 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]

### 3.2.2 Token and Session Security

| Configuration             | Value / Requirement                           |
|---------------------------|-----------------------------------------------|
| JWT Algorithm             | RS256 (RSA Signature with SHA-256)            |
| JWT Issuer                | https://login.microsoftonline.com/{tenant-id} |
| JWT Audience              | api://dentalcare-pro                          |
| Access Token Lifetime     | 15 minutes                                    |
| Refresh Token Lifetime    | 8 hours (sliding window)                      |
| CORS Allowed Origins      | Whitelist only (per environment)              |
| CSRF                      | SameSite=Strict cookies + double-submit       |
| Content-Security-Policy   | default-src ‘self’; script-src ‘self’         |
| X-Content-Type-Options    | nosniff                                       |
| X-Frame-Options           | DENY                                          |
| Strict-Transport-Security | max-age=31536000; includeSubDomains           |

[KB-06cbdf57-f5b7-42c6-9d15-4119f65cd34e]

### 3.2.3 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.4 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]

- **HIPAA Note:** All responses containing PHI must include `Cache-Control: no-store` and `Pragma: no-cache` to prevent client-side caching of health information. [KB-16e42083-f456-49a3-959d-419cdb9fc31d]

---

## 3.3 Reliability and Availability

- **System availability:** 99.9% (maximum 8.77 hours downtime per year). [KB-0d9e59c7-0414-46c2-b302-2f4cbc1e9e88]
- **No retry or circuit breaker on any cross-service call.** Failures are logged but not retried. [KB-01305cb3-d331-4b4b-ba02-69ada467b41d]
- **No bulk error handling for batch operations.** If one item in a batch fails, there is no mechanism to continue processing the remainder. [KB-04a84995-0820-4319-bd5e4ef2f03c0]
- **All inter-service API calls are synchronous REST over HTTP.** No message broker or asynchronous communication channel exists. [KB-0d7daadd-e958-4592-900a-55db91f8aa55]

---

## 3.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.      | 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.                                                   | All Services         | Medium     |

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

- **No bulk order import UI.** No CSV upload, no drag-and-drop, no batch creation form. [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]
- **N+1 API pattern for payments/notifications.** No list-all endpoints on backend. [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]
- **Client-side aggregation only.** Dashboard stats computed in browser. [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]
- **No real-time updates.** Polling-based, no WebSocket. [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]
- **Single-language (Japanese).** No i18n framework. [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]

---

## 3.5 Compliance Requirements

- **HIPAA Security:** All requirements for access control, audit logging, encryption, and data masking must be met as specified in the referenced controls. [KB-116f84fb-2eec-4493-9762-414a92624981]
- **Error responses and PHI:** No PHI or sensitive system details may be exposed in error responses. [KB-10300d8a-a98a-4726-9be3-3957c2fe7bf4]
- **PHI responses:** Must include HTTP headers to prevent client-side caching. [KB-16e42083-f456-49a3-959d-419cdb9fc31d]

---

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

If further non-functional requirements (e.g., maintainability, scalability, usability, environmental constraints) are required, additional data is needed.

---

**References:**  
- [KB-0d9e59c7-0414-46c2-b302-2f4cbc1e9e88]  
- [KB-146a6a29-932f-485d-96d6-6a92ee610336]  
- [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]  
- [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]  
- [KB-06c5403a-d177-4525-b247-1d7ae37a86b8]  
- [KB-0910e88e-c115-4412-a137-d96b5c1a2082]  
- [KB-06cbdf57-f5b7-42c6-9d15-4119f65cd34e]  
- [KB-10300d8a-a98a-4726-9be3-3957c2fe7bf4]  
- [KB-140ca7f3-3348-4419-b06b-89561882a35e]  
- [KB-116f84fb-2eec-4493-9762-414a92624981]  
- [KB-16e42083-f456-49a3-959d-419cdb9fc31d]  
- [KB-01305cb3-d331-4b4b-ba02-69ada467b41d]  
- [KB-04a84995-0820-4319-bd5e4ef2f03c0]  
- [KB-0d7daadd-e958-4592-900a-55db91f8aa55]  
- [KB-150eb89c-77b0-415b-a547-3ed0502eec24]

## 4. Architecture

# 4. Architecture

## 4.1 Architectural Overview

The current system architecture for order management is based on a microservices model, with a clear separation of concerns across Order Service, Payment Service, and Notification Service. The frontend is implemented as a React single-page application (SPA), which communicates with backend services via REST APIs. All inter-service communication is synchronous over HTTP; there is no message broker, event bus, or asynchronous channel implemented in the current system. The backend services are deployed on ECS Fargate, with core business logic implemented in Spring Boot applications. Data persistence is managed via PostgreSQL (AWS RDS), and audit logs are stored in PostgreSQL, CloudWatch, and Elasticsearch for analysis. The legacy system is based on Visual Basic 6.0 and SQL Server 2012, which is being migrated to the new architecture for improved maintainability, security, and scalability.  
[KB-050d0be4-11bc-4945-80e4-1f59d3187e45]  
[KB-0e90d327-2678-405f-b35a-294b5435dc66]  
[KB-17a58f06-2387-412d-bfbe73477c71a]  
[KB-0633e923-f925-4ff5-a5d6-d30346c26a5e]  
[KB-1a54c453-d6ee-488f-bbdc-311c467a9661]  
[KB-03d0d4be-6781-4fc5-af90-de8b326616c0]  

## 4.2 Major System Components

| Component                | Technology / Role                          | Description                                                                                   |
|--------------------------|--------------------------------------------|-----------------------------------------------------------------------------------------------|
| Frontend                 | React SPA                                  | User interface for order management, payment, and notification operations                     |
| Order Service            | Spring Boot (REST API)                     | Handles order creation, retrieval, update, and cancellation                                   |
| Payment Service          | Spring Boot (REST API)                     | Processes payments for individual orders                                                      |
| Notification Service     | Spring Boot (REST API)                     | Sends notifications (email/SMS) for order events                                              |
| Database                 | PostgreSQL (AWS RDS)                       | Stores orders, payments, audit logs, and related data                                         |
| Audit Storage            | PostgreSQL, CloudWatch, Elasticsearch      | Stores and analyzes audit logs for compliance and operational monitoring                      |
| Legacy System            | Visual Basic 6.0, SQL Server 2012          | Source system for migration; being decommissioned                                             |

[KB-0e90d327-2678-405f-b35a-294b5435dc66]  
[KB-03d0d4be-6781-4fc5-af90-de8b326616c0]  
[KB-17a58f06-2387-412d-bfbe73477c71a]  
[KB-1a54c453-d6ee-488f-bbdc-311c467a9661]  

## 4.3 Service Integration and Communication Patterns

All service-to-service communication is synchronous REST over HTTP. The following table summarizes the communication patterns and timeouts:

| Pattern                 | Usage                        | Timeout                |
|-------------------------|------------------------------|------------------------|
| Synchronous REST        | All inter-service calls       | 30 seconds (payment), 10 seconds (notification/webhook) |
| Webhook (REST callback) | Payment → Order status update | 10 seconds             |

No message queues, event buses, or asynchronous processing channels are present.  
[KB-0d7daadd-e958-4592-900a-55db91f8aa55]

## 4.4 Key Architectural Constraints

The current architecture enforces several critical constraints that impact extensibility and performance:

| Constraint 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     |

[KB-146a6a29-932f-485d-96d6-6a92ee610336]  
[KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]  
[KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c]  
[KB-04a84995-0820-4319-9d26-c1582821058a]  
[KB-150eb89c-77b0-415b-a547-3ed0502eec24]  

## 4.5 Data Model and Schema Constraints

- The orders table does **not** include batch_id, csv_source, or bulk_import_group columns. There is no mechanism to track which orders belong to a batch import.
- The payments table enforces a 1:1 relationship with orders (order_id is UNIQUE), preventing batch payment grouping.
- Maximum payment amount per transaction is 1,000,000 JPY; this applies per order, not per batch.

| Column         | Type    | Null | Constraint         | Notes                         |
|----------------|---------|------|-------------------|-------------------------------|
| order_id       | INTEGER | No   | UNIQUE            | 1:1 — batch grouping not possible |
| amount         | FLOAT   | No   |                   | Min 100 JPY, Max 1,000,000 JPY   |
| currency       | VARCHAR | No   | Default "JPY"     |                               |
| status         | ENUM    | No   |                   | PaymentStatus                 |
| payment_method | VARCHAR | No   | "credit_card"     |                               |
| transaction_id | VARCHAR | No   | UNIQUE            | UUID                          |

[KB-0f930ddc-1f3a-4014-a015-49fe1808f8d8]  
[KB-11739ab0-b209-41c0-b1db-9433cfedb7a3]  
[KB-10744011-e9ca-48b5-ac6d-4f9f3627b7e6]  

## 4.6 Order Processing Flow

Order creation and related operations are strictly sequential:

1. **Order Creation:** User submits order via frontend; Order Service creates order.
2. **Payment Processing:** Order Service calls Payment Service (POST /api/v1/payments) for each order. No batch payment API exists.
3. **Notification:** Notification Service is called for each order event (e.g., confirmation, cancellation). No bulk notification API exists.
4. **Webhook:** Payment Service notifies Order Service of payment status via webhook.

**Note:** For 10,000 orders, 10,000 API calls are required for both payment and notification, resulting in extremely slow bulk operations.  
[KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]  
[KB-150eb89c-77b0-415b-a547-3ed0502eec24]  
[KB-04a84995-0820-4319-9d26-c1582821058a]  

## 4.7 Security Architecture

- Authentication: OAuth 2.0 Resource Server with Azure AD integration.
- Authorization: Method-level enforcement using @PreAuthorize with SpEL.
- CSRF Protection: SameSite cookies and CSRF tokens.
- Rate Limiting: Bucket4j with Redis backend.
- Session Management: Stateless (JWT) with Redis token blacklist.
- Encryption: All data at rest (database, files, field-level) is encrypted using AES-256; all communications use TLS 1.3.
- Audit Logging: Comprehensive audit trail for all PHI access and modifications.

[KB-0910e88e-c115-4412-a137-d96b5c1a2082]  
[KB-116f84fb-2eec-4493-9762-414a92624981]  
[KB-05741ca9-5822-4eb0-91b0-d660322e06d0]  
[KB-15596807-701d-4357-8083-5cc6d631106b]  

## 4.8 Audit and Compliance

- All PHI access, modifications, and disclosures are logged with user, patient, action, and timestamp.
- Audit logs are retained for 7-8 years, with tiered storage (hot, warm, cold) for compliance.
- De-identification is enforced in all non-production environments.

| Log Category            | Hot Storage | Warm Storage | Cold Storage | 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         |
| Security events         | 180 days    | 2 years      | 6 years      | 8 years         |

[KB-059dda76-1df0-4539-a60b-e504ba4e11ea]  
[KB-03f9d790-a1e6-46b9-8aeb-0fc45505be6a]  
[KB-122ffdd6-c824-4443-8d2b-baab3d94a6ec]  

## 4.9 Known Technical Debt and Migration Risks

- No bulk or batch order import, payment, or notification capability.
- N+1 API pattern for payments and notifications; no backend aggregation endpoints.
- No real-time updates (polling only, no WebSocket).
- Single-language (Japanese); no i18n framework.
- No retry or circuit breaker for cross-service calls; failures are logged but not retried.
- Legacy system (VB6/SQL Server 2012) is end-of-life and presents significant security risk.

[KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]  
[KB-17a58f06-2387-412d-bfbe73477c71a]  
[KB-03d0d4be-6781-4fc5-af90-de8b326616c0]  
[KB-18fdad59-c9a9-48f7-90db-0fb2b2957948]  

---

**Summary:**  
The current architecture is a microservices-based system with strong security and audit controls but is limited by the absence of bulk processing capabilities and parallelization. All order, payment, and notification operations are strictly single-entry and sequential, resulting in significant performance and scalability constraints for high-volume operations.  
All content above is strictly based on the provided context and does not include any external or assumed information.