## 1. Introduction

# 1. Introduction

## 1.1 Purpose

This document defines the functional and non-functional requirements, constraints, and architectural boundaries for the Order Management and Payment Processing system. The scope includes detailed limitations of the current system, business requirements for CSV-based bulk order import, and cross-service integration rules. All requirements are grounded in the provided context and validated against system-level constraints and business needs. The document is intended for technical stakeholders, developers, and compliance officers involved in system enhancement, migration, or integration projects.  
[KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-1603dccf-0e13-426d-a4c3-527af9e69c16], [KB-16181d30-2dd3-421e-bab0-939cd85255d2], [KB-155b5f4a-d232-4166-bb96-ba158f86ceb1]

## 1.2 Scope

The requirements herein cover:

- Order creation, management, and payment processing workflows
- CSV import and batch processing constraints
- Service integration contracts (Order, Payment, Notification)
- System limitations impacting bulk operations, payment aggregation, and notification throughput

This document does not address clinical, scheduling, or patient management requirements outside the order/payment domain.

## 1.3 Intended Audience

- Software architects and engineers
- Product managers and business analysts
- Compliance and security officers
- QA and integration teams

## 1.4 System Overview

The Order Management system operates as a REST API-based backend, supporting single-order creation only. Bulk order import via CSV or file upload is not currently available. Payment processing is strictly one transaction per order, with no batch payment capability. Notification services send one message per API call, subject to rate limits. All cross-service calls are executed sequentially, with no parallel processing or retry mechanisms.  
[KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a], [KB-10744011-e9ca-48b5-ac6d-4f9f3627b7e6], [KB-150eb89c-77b0-415b-a547-3ed0502eec24]

## 1.5 Document Structure

This document is organized according to ISO-29148 requirements engineering standards:

- Section 1: Introduction
- Section 2: Functional Requirements
- Section 3: Non-Functional Requirements
- Section 4: Constraints and Limitations
- Section 5: Cross-Service Integration
- Section 6: Data Requirements
- Section 7: Compliance and Security
- Section 8: Approval and Revision History

## 1.6 References

- System Limitations Table  
  [KB-146a6a29-932f-485d-96d6-6a92ee610336]
- Bulk Import Business Requirements  
  [KB-1603dccf-0e13-426d-a4c3-527af9e69c16], [KB-155b5f4a-d232-4166-bb96-ba158f86ceb1]
- UI and API Integration Details  
  [KB-16181d30-2dd3-421e-bab0-939cd85255d2]
- Payment and Notification Constraints  
  [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a], [KB-10744011-e9ca-48b5-ac6d-4f9f3627b7e6], [KB-150eb89c-77b0-415b-a547-3ed0502eec24]

---

*All content is strictly derived from the provided context. No external information has been introduced.*

## 2. Functional Requirements

# 2. Functional Requirements

This section specifies the functional requirements for the order management and related services, as derived from the provided knowledge base. All requirements reflect the current system capabilities and constraints.

---

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

[KB-0e0f1dd0-0f46-4d13-a092-e3cdc6fdd205]

---

## 2.2 Order Listing and Retrieval

| Requirement ID | Description                                                                                             | Priority |
|----------------|--------------------------------------------------------------------------------------------------------|----------|
| FR-003         | The system must provide a paginated list of orders, 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, returning all associated order items.    | P1       |

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

---

## 2.3 Order Status Management

| Requirement ID | Description                                                                                             | Priority |
|----------------|--------------------------------------------------------------------------------------------------------|----------|
| FR-005         | The system must support updating the status of an order. Setting status to SHIPPED triggers a shipping notification. | P1       |
| FR-006         | The system must allow cancellation of an order, which triggers both a refund via the Payment Service and a cancellation email via the Notification Service. | P1       |

[KB-0972bd0e-7d3-4b2c-a364-813e023a3495]

---

## 2.4 Payment Processing Integration

| Requirement ID | Description                                                                                             | Priority |
|----------------|--------------------------------------------------------------------------------------------------------|----------|
| FR-007         | For each order, the system must initiate a payment transaction via the Payment Service API. Only one payment can be processed per API call (no batch payments). | P1       |
| FR-008         | The system must enforce payment amount limits: minimum 100 JPY, maximum 1,000,000 JPY per transaction. High-value orders exceeding this limit must be rejected. | P1       |
| FR-009         | The system must allow retrieval of payment information by order ID and support refund processing on order cancellation. | P1       |

[KB-186b33d7-f985-455b-8117-0cd019912510], [KB-05a9aed3-6a71-4c74-ac19-6bfec293268b], [KB-10744011-e9ca-48b5-ac6d-4f9f3627b7e6]

---

## 2.5 Notification Service Integration

| Requirement ID | Description                                                                                             | Priority |
|----------------|--------------------------------------------------------------------------------------------------------|----------|
| FR-010         | The system must send an individual notification (e.g., email) for each order event (confirmation, shipping, cancellation) via the Notification Service API. No bulk notification API exists; each notification requires a separate API call. | P1       |
| FR-011         | Notification sending is rate-limited to 10 requests per second. Large batch operations (e.g., 10,000 notifications) will require a minimum of 1,000 seconds. | P1       |

[KB-05a9aed3-6a71-4c74-ac19-6bfec293268b], [KB-06c5403a-d177-4525-b247-1d7ae37a86b8], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]

---

## 2.6 Bulk/Batch Operations

| Requirement ID | Description                                                                                             | Priority |
|----------------|--------------------------------------------------------------------------------------------------------|----------|
| LIM-001        | The system does NOT support bulk or batch order creation. Orders must be created one at a time via the REST API. | High     |
| LIM-002        | The system does NOT support CSV/file-based order import. There is no endpoint or mechanism to upload and process order data from files. | High     |
| LIM-003        | The system does NOT support batch payment processing. Each order requires a separate payment API call.  | High     |
| LIM-004        | The system does NOT support bulk notification sending. Each notification requires a separate API call.  | Medium   |

[KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]

---

## 2.7 Cross-Service Communication

| Requirement ID | Description                                                                                             | Priority |
|----------------|--------------------------------------------------------------------------------------------------------|----------|
| FR-012         | All inter-service communication is synchronous REST over HTTP. No message broker, event bus, or asynchronous channel is used. | P1       |
| FR-013         | Service call timeouts: 30 seconds for Payment Service, 10 seconds for Notification Service and Webhook callbacks. | P1       |

[KB-0d7daadd-e958-4592-900a-55db91f8aa55]

---

## 2.8 Error Handling

| Requirement ID | Description                                                                                             | Priority |
|----------------|--------------------------------------------------------------------------------------------------------|----------|
| FR-014         | If a payment or notification call fails during order creation, the error is logged and the order status is reverted to PENDING. No retry or circuit breaker mechanism is implemented. | P1       |
| FR-015         | Error responses in production must never contain PHI, stack traces, SQL queries, internal file paths, server names, or framework version information. | Critical |

[KB-033639ab-c6f8-4f72-a373-bf76d05dd6cf], [KB-10300d8a-a98a-4726-9be3-3957c2fe7bf4], [KB-140ca7f3-3348-4419-b06b-89561882a35e]

---

## 2.9 Order Data Model Constraints

| Requirement ID | Description                                                                                             | Priority |
|----------------|--------------------------------------------------------------------------------------------------------|----------|
| LIM-005        | The orders table does NOT include batch_id, csv_source, or bulk_import_group columns. Orders cannot be tracked or grouped as part of a batch import. | High     |

[KB-0f930ddc-1f3a-4014-a015-49fe1808f8d8], [KB-02c65582-456a-4ffe-8d87-e4cff20e9718]

---

## 2.10 Progress Tracking

| Requirement ID | Description                                                                                             | Priority |
|----------------|--------------------------------------------------------------------------------------------------------|----------|
| LIM-006        | The system does NOT provide progress tracking for batch operations, as no batch operations exist.      | Medium   |

[KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]

---

## 2.11 User Interface

| Requirement ID | Description                                                                                             | Priority |
|----------------|--------------------------------------------------------------------------------------------------------|----------|
| FR-016         | The order management UI must display a warning banner and disable the CSV import button, indicating that CSV import is not implemented. | P1       |
| FR-017         | The UI must support client-side filtering by customer name/email, status filtering, sorting, and single order creation. | P1       |

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

---

## 2.12 Performance

| Requirement ID | Description                                                                                             | Priority |
|----------------|--------------------------------------------------------------------------------------------------------|----------|
| FR-018         | All order creation, payment, and notification operations are executed sequentially (not in parallel). For large volumes, total processing time is the sum of each operation’s duration. | P1       |

[KB-150eb89c-77b0-415b-a547-3ed0502eec24], [KB-033639ab-c6f8-4f72-a373-bf76d05dd6cf]

---

**End of Functional Requirements**

## 3. Non-Functional Requirements

# 3. Non-Functional Requirements

## 3.1 Performance Requirements

- **API Response Times:**  
  - p50: < 200ms  
  - p95: < 500ms  
  - p99: < 1,000ms  
  - Measurement: Application metrics  
  - Reference: [KB-0d9e59c7-0414-46c2-b302-2f4cbc1e9e88]

- **Page Load Times:**  
  - Initial: < 2 seconds  
  - Subsequent: < 1 second  
  - Measurement: Lighthouse, client-side metrics  
  - Reference: [KB-0d9e59c7-0414-46c2-b302-2f4cbc1e9e88]

- **System Availability:**  
  - 99.9% uptime (maximum 8.77 hours/year downtime)  
  - Measurement: Uptime monitoring  
  - Reference: [KB-0d9e59c7-0414-46c2-b302-2f4cbc1e9e88]

- **Database Query Time:**  
  - Average: < 100ms  
  - Measurement: RDS Performance Insights  
  - Reference: [KB-0d9e59c7-0414-46c2-b302-2f4cbc1e9e88]

- **Concurrent Users:**  
  - 500+ simultaneous users supported  
  - Measurement: Load testing  
  - Reference: [KB-0d9e59c7-0414-46c2-b302-2f4cbc1e9e88]

- **API Throughput:**  
  - > 1,000 requests/second  
  - Reference: [KB-0d9e59c7-0414-46c2-b302-2f4cbc1e9e88]

- **Notification Service Rate Limit:**  
  - 10 notifications/second  
  - Bulk notification not supported; sending 10,000 notifications requires minimum 17 minutes  
  - Reference: [KB-06c5403a-d177-4525-b247-1d7ae37a86b8], [KB-04a84995-0820-4319-9d26-c1582821058a]

- **Order Creation Flow:**  
  - Sequential execution for cross-service calls (Order → Payment → Notification)  
  - No parallel processing; total latency is sum of each step  
  - Reference: [KB-033639ab-c6f8-4f72-a373-bf76d05dd6cf], [KB-150eb89c-77b0-415b-a547-3ed0502eec24]

## 3.2 Reliability Requirements

- **Incident Response:**  
  - Documented and tested incident response plan  
  - Dedicated incident response team (Security Officer, Privacy Officer, Legal Counsel, IT Lead)  
  - Incident reporting via JIRA Security Queue and hotline  
  - Post-incident review and breach notification procedures  
  - Reference: [KB-052c37cd-e1b9-4e3f-8d87-e4cff20e9718]

- **Alert Response Procedures:**  
  - Service down, database unreachable, error rate >15%: Immediate investigation and escalation  
  - API latency >3s (p99): Performance engineering review  
  - Reference: [KB-07666b95-1860-4b27-ad63-b0c0bc85ccdb]

- **Audit Controls:**  
  - Comprehensive audit logging required  
  - Audit logs retained for up to 8 years, with hot, warm, and cold storage tiers  
  - Reference: [KB-059dda76-1df0-4539-a60b-e504ba4e11ea]

- **Error Handling:**  
  - No retry or circuit breaker on cross-service calls; failures are logged and revert status to PENDING  
  - Reference: [KB-033639ab-c6f8-4f72-a373-bf76d05dd6cf], [KB-150eb89c-77b0-415b-a547-3ed0502eec24]

## 3.3 Security Requirements

- **Authentication & Authorization:**  
  - OAuth 2.0 Resource Server + Azure AD  
  - Method-level authorization (@PreAuthorize with SpEL)  
  - Reference: [KB-0910e88e-c115-4412-a137-d96b5c1a2082]

- **Multi-Factor Authentication (MFA):**  
  - Required for web login, VPN, AWS Console, administrative actions, PHI bulk export, and emergency access  
  - Reference: [KB-131c1759-15a3-44df-a1d7-6ebd04de62ff]

- **Session Management:**  
  - Stateless (JWT) with Redis token blacklist  
  - Access token lifetime: 15 min; refresh token: 8 hours  
  - Reference: [KB-06cbdf57-f5b7-42c6-9d15-4119f65cd34e]

- **Encryption:**  
  - At rest: Full database, files, and field-level encryption (AES-256, S3 SSE-KMS, JPA AttributeConverter + AES-256-GCM)  
  - In transit: TLS 1.3 only  
  - Key management: AWS KMS (customer-managed CMKs)  
  - Reference: [KB-116f84fb-2eec-4493-9762-414a92624981]

- **Input/Output Validation:**  
  - Bean Validation + custom validators  
  - OWASP Java Encoder for output encoding  
  - Reference: [KB-0910e88e-c115-4412-a137-d96b5c1a2082]

- **Error Message Security:**  
  - Production error responses must not contain PHI, stack traces, SQL queries, internal file paths, server names, or framework version information  
  - Reference: [KB-10300d8a-a98a-4726-9be3-3957c2fe7bf4], [KB-140ca7f3-3348-4419-b06b-89561882a35e]

- **Data Masking:**  
  - Dev/test environments use synthetic data pipeline for PHI masking  
  - Reference: [KB-116f84fb-2eec-4493-9762-414a92624981]

- **Regulatory Compliance:**  
  - HIPAA requirements enforced: unique user identification, emergency access, automatic logoff, encryption, audit controls, integrity, authentication  
  - Reference: [KB-0f3989d4-36c1-4054-923c-c250f04c3ec3]

## 3.4 Scalability Requirements

- **API Throughput:**  
  - System must support >1,000 requests/second  
  - Reference: [KB-0d9e59c7-0414-46c2-b302-2f4cbc1e9e88]

- **Concurrent Users:**  
  - 500+ simultaneous users  
  - Reference: [KB-0d9e59c7-0414-46c2-b302-2f4cbc1e9e88]

- **Batch Processing Limitations:**  
  - No batch/bulk order creation or payment processing; all operations are single-entry and sequential  
  - Reference: [KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f], [KB-10744011-e9ca-48b5-ac6d-4f9f3627b7e6]

## 3.5 Maintainability Requirements

- **Audit Trail Continuity:**  
  - No gaps between legacy and new system logs during migration  
  - Reference: [KB-1554a441-9086-4371-85f6-cb4d7472ee1b]

- **Versioning:**  
  - URI-based versioning with major version in path (e.g., /v1/patients)  
  - Only major versions in URL; minor/patch changes are backward-compatible  
  - Deprecation notice: minimum 6 months before version retirement  
  - Maximum 2 active versions at any time  
  - Reference: [KB-10300d8a-a98a-4726-9be3-3957c2fe7bf4], [KB-140ca7f3-3348-4419-b06b-89561882a35e]

## 3.6 Usability Requirements

- **Accessibility:**  
  - React UI must comply with WCAG 2.1 AA accessibility standards  
  - Reference: [KB-0a1640fc-d3df-49c8-9862-d52514894afd]

## 3.7 System Limitations

| 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.            | 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-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f], [KB-10744011-e9ca-48b5-ac6d-4f9f3627b7e6], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a], [KB-150eb89c-77b0-415b-a547-3ed0502eec24]

---

If additional non-functional requirements are needed, please provide further context.

## 4. Architecture

# 4. Architecture

## 4.1 Architectural Overview

The current system is architected as a web-based order management platform with a React single-page application (SPA) frontend and three backend microservices. All inter-service communication is performed synchronously over REST APIs. The architecture is deployed on an ECS Fargate cluster, with backend services implemented primarily in Spring Boot, and data persisted in PostgreSQL (AWS RDS). The system does not utilize message brokers, event buses, or asynchronous communication channels; all service-to-service calls are synchronous HTTP requests with defined timeouts ([KB-050d0be4-11bc-4945-80e4-1f59d3187e45], [KB-0d7daadd-e958-4592-900a-55db91f8aa55], [KB-0e90d327-2678-405f-b35a-294b5435dc66]).

### High-Level Component Diagram

```
┌─────────────────────────────┐
│      React SPA Frontend     │
└─────────────┬───────────────┘
              │
      REST API Calls (HTTPS)
              │
┌─────────────▼───────────────┐
│   Spring Boot API Service   │
│   Spring Boot Clinical Svc  │
│   Spring Boot Notification  │
└─────────────┬───────────────┘
              │
         Data Subnet
              │
        PostgreSQL (RDS)
```
([KB-0e90d327-2678-405f-b35a-294b5435dc66], [KB-06b60bcb-670e-4bab-9e15-f53ba7eda959], [KB-17311270-7a01-481a-491f-b894-1fd70c185060])

## 4.2 Service Interfaces and Data Flow

### 4.2.1 Order Creation and Processing

- Orders are created one at a time through the REST API. There is no support for bulk or batch order creation, nor for CSV/file-based import ([KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]).
- Each order triggers a payment processing request to the Payment Service and a notification to the Notification Service. Both are executed sequentially, not in parallel ([KB-033639ab-c6f8-4f72-a373-bf76d05dd6cf], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a], [KB-150eb89c-77b0-415b-a547-3ed0502eec24]).
- Payment and notification APIs are strictly one-to-one: one order per payment transaction, one notification per API call. There is no batch or aggregate transaction capability ([KB-10744011-e9ca-48b5-ac6d-4f9f3627b7e6], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a], [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c]).
- The system enforces a maximum transaction amount of 1,000,000 JPY per order ([KB-01305cb3-d331-4b4b-ba02-69ada467b41d], [KB-186b33d7-f985-455b-8117-0cd019912510], [KB-10744011-e9ca-48b5-ac6d-4f9f3627b7e6]).
- There is no mechanism for tracking progress or partial failures in batch operations, as batch operations are not supported ([KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]).

### 4.2.2 Service Integration

| Service         | Integration Method | Endpoint Example                       | Timeout | Retry | Notes                                 |
|-----------------|-------------------|----------------------------------------|---------|-------|---------------------------------------|
| Payment Service | REST (sync)       | POST /api/v1/payments                  | 30 sec  | None  | One order per call                    |
| Notification    | REST (sync)       | POST /api/v1/notifications/email       | 10 sec  | None  | One notification per call, 10/sec max |
| Webhook         | REST (callback)   | POST /api/v1/orders/{order_id}/webhook | 10 sec  | None  | Payment status update                 |

([KB-0d3f16d9-bca7-4fde-a49e-b12798f2f65f], [KB-0d7daadd-e958-4592-900a-55db91f8aa55], [KB-1718c2d8-b71b-4113-9906-a6d9765958ff])

### 4.2.3 Data Model and Constraints

- Orders, payments, and notifications are strictly 1:1. There are no batch/grouping fields (e.g., batch_id, bulk_import_group) in the schema ([KB-0f930ddc-1f3a-4014-a015-49fe1808f8d8], [KB-11739ab0-b209-41e4-b73e-7d7e0c4338b2]).
- Payment records are uniquely linked to orders (order_id UNIQUE). Amount must be between 100 JPY and 1,000,000 JPY ([KB-11739ab0-b209-41e4-b73e-7d7e0c4338b2], [KB-186b33d7-f985-455b-8117-0cd019912510]).
- There is no support for aggregating multiple orders into a single transaction ([KB-10744011-e9ca-48b5-ac6d-4f9f3627b7e6]).

## 4.3 Security Architecture

- Authentication is implemented using OAuth 2.0 Resource Server with Azure AD integration ([KB-0910e88e-c115-4412-a137-d96b5c1a2082]).
- Authorization is enforced at the method level using @PreAuthorize annotations with SpEL ([KB-0910e88e-c115-4412-a137-d96b5c1a2082]).
- All communications are encrypted in transit using TLS 1.3 ([KB-116f84fb-2eec-4493-9762-414a92624981]).
- Data at rest is encrypted using AWS RDS encryption (AES-256) ([KB-116f84fb-2eec-4493-9762-414a92624981]).
- Session management is stateless via JWT, with Redis token blacklist ([KB-0910e88e-c115-4412-a137-d96b5c1a2082]).
- Strict security headers and CORS policies are enforced ([KB-06cbdf57-f5b7-42c6-9d15-4119f65cd34e], [KB-0910e88e-c115-4412-a137-d96b5c1a2082]).
- Error responses in production must not contain PHI, stack traces, SQL queries, internal file paths, server names, or framework version information ([KB-10300d8a-a98a-4726-9be3-3957c2fe7bf4], [KB-140ca7f3-3348-4419-b06b-89561882a35e]).

## 4.4 Architectural Constraints and 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.                                                          | All Services         | Medium   |

([KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f], [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c], [KB-0f930ddc-1f3a-4014-a015-49fe1808f8d8], [KB-10744011-e9ca-48b5-ac6d-4f9f3627b7e6])

**Key Implications:**
- Large-scale order processing (e.g., 10,000 orders) requires 10,000 individual API calls, resulting in extremely slow throughput ([KB-150eb89c-77b0-415b-a547-3ed0502eec24]).
- Notification rate is limited to 10/sec; 10,000 notifications require a minimum of ~17 minutes ([KB-01305cb3-d331-4b4b-ba02-69ada467b41d], [KB-06c5403a-d177-4525-b247-1d7ae37a86b8]).
- There is no retry or circuit breaker for failed cross-service calls ([KB-01305cb3-d331-4b4b-ba02-69ada467b41d], [KB-150eb89c-77b0-415b-a547-3ed0502eec24]).
- No mechanism exists for tracking or recovering from partial failures in batch operations ([KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]).

## 4.5 Summary Table: Core Building Blocks

| Layer/Component        | Technology / Service          | Notes                                             |
|------------------------|------------------------------|---------------------------------------------------|
| Frontend               | React SPA                    | Single-page application                           |
| API Layer              | Spring Boot                  | RESTful APIs, OAuth2, JWT                         |
| Order Service          | Spring Boot                  | Single order creation, no batch import            |
| Payment Service        | Spring Boot                  | 1:1 payment per order, no batch API               |
| Notification Service   | Spring Boot                  | 1:1 notification per order, 10/sec rate limit     |
| Database               | PostgreSQL (AWS RDS)         | Encrypted at rest                                 |
| Infrastructure         | ECS Fargate                  | Managed container orchestration                   |
| Security               | OAuth2, Azure AD, TLS 1.3    | Method-level authorization, strict headers        |

([KB-0e90d327-2678-405f-b35a-294b5435dc66], [KB-116f84fb-2eec-4493-9762-414a92624981], [KB-0910e88e-c115-4412-a137-d96b5c1a2082])

---

**End of Section 4. Architecture**