### 🔍 PHASE 1 — REQUIREMENTS RECONSTRUCTION ### 1.1 Business capabilities | Capability | Description | | -------------------- | --------------------------------- | | User management | Student, professor, administrator | | Equipment management | Register and update equipment | | Booking management | Reserve and cancel equipment | | Availability | View available time slots | | Maintenance | Track repair activities | | Calibration | Track calibration deadlines | | Notifications | Booking and maintenance alerts | | Audit | Record administrative changes | ### 1.2 Critical user journeys Journey 1: Equipment booking * Student logs in. * Searches for equipment. * Selects an available time slot. * Submits a booking request. * Backend validates authorization and availability. * Database creates the booking transactionally. * Notification is queued. * Student receives confirmation. Journey 2: Equipment maintenance * Administrator identifies damaged equipment. * Changes equipment status to maintenance. * System prevents new reservations. * Existing future bookings are identified. * Administrator reviews affected reservations. * Notifications are sent to affected users. Journey 3: Calibration tracking * System identifies upcoming calibration deadlines. * Background job checks due dates. * Administrator receives an alert. * Administrator records calibration results. * Equipment status is updated according to the result. ### 1.3 Requirement classification | Classification | Example | | ------------------- | --------------------------------------------------------- | | FACT | University requires equipment booking | | REQUIREMENT | Prevent overlapping reservations | | DERIVED REQUIREMENT | Booking creation must be transactional | | ASSUMPTION | One equipment item cannot serve two simultaneous bookings | | PROPOSED DECISION | PostgreSQL exclusion constraints | | UNRESOLVED QUESTION | Are professor bookings prioritized over student bookings? | ### 1.4 Non-functional acceptance criteria | Requirement | Acceptance criterion | | ----------------- | ------------------------------------------------------ | | Availability | Target 99.9% monthly | | Read latency | p95 below 300 ms | | Booking integrity | Zero confirmed overlapping reservations | | Security | Server-side authorization on every protected operation | | Growth | Support 50,000 registered users | | Recovery | Proposed RTO 2 hours | | Data recovery | Proposed RPO 15 minutes | RTO and RPO are proposed planning targets, not confirmed business requirements. ### 1.5 Unresolved questions * Can students book multiple equipment items simultaneously? * Are bookings subject to professor approval? * What is the maximum booking duration? * How long must calibration records be retained? * Should maintenance automatically cancel future bookings? ### 📊 PHASE 2 — WORKLOAD MODEL AND CAPACITY ESTIMATION ### 2.1 Baseline workload | Metric | Estimate | | -------------------- | --------------------- | | Registered users | 15,000 | | Daily active users | 3,000 | | Peak concurrency | 500 | | Monthly bookings | 100,000 | | Average bookings/day | 3,333 | | Booking API requests | Assumed 5 per booking | ### 2.2 Request rate calculation Assume 20 API requests per daily active user. Daily requests: 3,000 \\times 20 = 60,000 Average requests per second: 60,000 / 86,400 = 0.69 Assume peak multiplier of 10. 0.69 \\times 10 = 6.9 Peak traffic approximately 7 requests/second. This is an initial estimate, not a benchmark. ### 2.3 Booking workload Monthly bookings: 100,000 / 30 = 3,333 Average booking creations per second: 3,333 / 86,400 = 0.039 Assuming a peak multiplier of 20: 0.039 \\times 20 = 0.77 Peak booking creation estimate: approximately 1 booking/second. ### 2.4 Storage estimate Assumptions: * Average booking record: 2 KB. * Monthly bookings: 100,000. * Annual booking volume: 1.2 million. Annual raw booking storage: 1,200,000 \\times 2KB = 2.4GB This excludes indexes, audit logs, backups, and maintenance records. ### 2.5 Capacity scenarios | Scenario | Registered users | Daily active users | Monthly bookings | | -------- | ---------------- | ------------------ | ---------------- | | Low | 8,000 | 1,500 | 50,000 | | Baseline | 15,000 | 3,000 | 100,000 | | High | 50,000 | 12,000 | 400,000 | ### 2.6 Measurements required * Actual requests per user. * Peak concurrent sessions. * Booking creation latency. * Database connection utilization. * Notification delivery rate. * Database growth. * Equipment availability query performance. ### 🧱 PHASE 3 — SYSTEM BOUNDARIES AND DOMAIN DECOMPOSITION ### 3.1 Domain modules | Module | Responsibility | | ------------ | -------------------------- | | Identity | User identity and roles | | Equipment | Equipment inventory | | Booking | Reservation lifecycle | | Maintenance | Repair and service records | | Calibration | Calibration schedules | | Notification | Email and SMS | | Audit | Administrative activity | ### 3.2 Architecture alternatives Alternative A: Modular Monolith * One deployable backend. * Independent internal modules. * Shared PostgreSQL database. * Background notification worker. Alternative B: Microservices * Separate equipment service. * Separate booking service. * Separate maintenance service. * Separate notification service. * Distributed communication and data ownership. ### 3.3 Selection Modular monolith. Reason: * Current workload does not justify distributed service complexity. * Booking transactions need strong consistency. * One database simplifies transaction management. * Smaller operational burden. * Easier debugging and deployment. Microservices can be considered later if independent scaling or team ownership becomes necessary. ### ⚖️ PHASE 4 — ARCHITECTURE ALTERNATIVES AND SELECTION | Criteria | Modular Monolith | Microservices | | ---------------------- | ---------------- | ------------- | | Initial cost | Lower | Higher | | Development complexity | Moderate | High | | Deployment | Simpler | Complex | | Booking consistency | Easier | More complex | | Independent scaling | Limited | Better | | Failure isolation | Moderate | Better | | Operational burden | Lower | Higher | Decision: Start with the modular monolith. Reconsider microservices when: * Individual modules require substantially different scaling. * Multiple teams need independent deployments. * Deployment coupling becomes a measurable problem. * Independent failure isolation becomes a business requirement. ### 🗺️ PHASE 5 — SYSTEM DIAGRAMS ### 5.1 System context diagram ```mermaid flowchart TB Student[Students] Professor[Professors] Admin[Lab Administrators] System[University Lab Management Platform] OAuth[University OAuth Provider] Email[Email Provider] SMS[SMS Provider] Student --> System Professor --> System Admin --> System System <--> OAuth System --> Email System --> SMS ``` ### 5.2 Component diagram ```mermaid flowchart TB UI[React Frontend] API[FastAPI Backend] subgraph Modules IAM[Identity Module] EQ[Equipment Module] BK[Booking Module] MT[Maintenance Module] CAL[Calibration Module] AUD[Audit Module] NOT[Notification Module] end DB[(PostgreSQL)] REDIS[(Redis)] WORKER[Background Worker] PROVIDER[Email and SMS Providers] UI --> API API --> IAM API --> EQ API --> BK API --> MT API --> CAL API --> AUD BK --> DB EQ --> DB MT --> DB CAL --> DB AUD --> DB API --> REDIS DB --> WORKER WORKER --> NOT NOT --> PROVIDER ``` ### 5.3 Booking data flow ```mermaid flowchart TD A[User submits booking] B[Authenticate user] C[Check authorization] D[Validate booking data] E[Check equipment availability] F[Database transaction] G[Save booking] H[Create notification event] I[Worker processes notification] J[Send confirmation] A --> B --> C --> D --> E --> F --> G --> H --> I --> J E -->|Unavailable| X[Reject booking] F -->|Conflict| X ``` ### 5.4 Deployment diagram ```mermaid flowchart TB Internet[Internet] LB[Cloud Load Balancer] subgraph Cloud APP1[FastAPI Instance 1] APP2[FastAPI Instance 2] DB[(Managed PostgreSQL)] CACHE[(Redis)] WORKER[Notification Worker] STORAGE[Object Storage] MON[Monitoring] end Internet --> LB LB --> APP1 LB --> APP2 APP1 --> DB APP2 --> DB APP1 --> CACHE APP2 --> CACHE DB --> WORKER WORKER --> STORAGE APP1 --> MON APP2 --> MON WORKER --> MON ``` ### 5.5 Booking sequence diagram ```mermaid sequenceDiagram participant U as Student participant API as FastAPI participant DB as PostgreSQL participant W as Worker participant N as Notification Provider U->>API: POST /bookings API->>API: Authenticate and authorize API->>DB: Begin transaction API->>DB: Insert booking DB-->>API: Booking created API->>DB: Insert outbox event API->>DB: Commit API-->>U: 201 Created W->>DB: Read pending event W->>N: Send confirmation N-->>W: Delivery response W->>DB: Mark event processed ``` ### 🔌 PHASE 6 — API CONTRACT AND INTEGRATION DESIGN ### 6.1 API design Use REST APIs with JSON. Base route: `/api/v1` | Method | Endpoint | Purpose | | ------ | ----------------------- | -------------------- | | GET | /equipment | List equipment | | GET | /equipment/ | Equipment details | | POST | /bookings | Create booking | | GET | /bookings/ | Booking details | | GET | /bookings | List user's bookings | | PATCH | /bookings//cancel | Cancel booking | | POST | /equipment | Register equipment | | PATCH | /equipment/ | Update equipment | | POST | /equipment//maintenance | Record maintenance | ### 6.2 Booking request ```json { "equipment_id": "EQ-1001", "start_time": "2026-11-02T10:00:00+05:30", "end_time": "2026-11-02T11:00:00+05:30" } ``` ### 6.3 Booking response ```json { "booking_id": "BK-5001", "status": "CONFIRMED", "equipment_id": "EQ-1001", "start_time": "2026-11-02T10:00:00+05:30", "end_time": "2026-11-02T11:00:00+05:30" } ``` ### 6.4 Error structure ```json { "error": { "code": "BOOKING_CONFLICT", "message": "Equipment is unavailable.", "request_id": "req-12345" } } ``` ### 6.5 Status codes | Status | Meaning | | ------ | ---------------------- | | 200 | Successful operation | | 201 | Booking created | | 400 | Invalid request | | 401 | Unauthenticated | | 403 | Unauthorized | | 404 | Resource not found | | 409 | Booking conflict | | 422 | Validation failure | | 429 | Rate limit exceeded | | 500 | Internal error | | 503 | Dependency unavailable | ### 6.6 API security and reliability * OAuth 2.0 access-token validation. * Role and ownership checks on the backend. * Idempotency key for booking creation. * Request validation using Pydantic. * Pagination for listing endpoints. * Bounded retries for external notification failures. * Request correlation IDs. * Versioned API routes. ### 🗄️ PHASE 7 — DATABASE AND DATA ARCHITECTURE Primary database: PostgreSQL. ### 7.1 Core entities | Table | Important fields | | ------------- | ------------------------------------------------------- | | users | id, email, name, role | | equipment | id, name, category, status | | bookings | id, user_id, equipment_id, start_time, end_time, status | | maintenance | id, equipment_id, description, status | | calibration | id, equipment_id, calibration_date, next_due_date | | audit_logs | id, actor_id, action, entity_id, created_at | | outbox_events | id, event_type, payload, status | ### 7.2 Relationships ```mermaid erDiagram USERS ||--o{ BOOKINGS : creates EQUIPMENT ||--o{ BOOKINGS : reserved_for EQUIPMENT ||--o{ MAINTENANCE : receives EQUIPMENT ||--o{ CALIBRATION : undergoes USERS ||--o{ AUDIT_LOGS : performs ``` ### 7.3 Booking table design ```sql CREATE TABLE bookings ( id UUID PRIMARY KEY, user_id UUID NOT NULL REFERENCES users(id), equipment_id UUID NOT NULL REFERENCES equipment(id), start_time TIMESTAMPTZ NOT NULL, end_time TIMESTAMPTZ NOT NULL, status VARCHAR(20) NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), CHECK (end_time > start_time) ); ``` ### 7.4 Preventing overlapping bookings Use PostgreSQL range exclusion constraints for active reservations. Conceptually: ```sql EXCLUDE USING GIST ( equipment_id WITH =, tstzrange(start_time, end_time, '[)') WITH && ) WHERE (status IN ('CONFIRMED', 'PENDING')); ``` This requires the appropriate GiST operator class, such as `btree_gist`, to be installed. The database constraint is the final protection against concurrent booking conflicts. ### 7.5 Index strategy * `bookings(user_id, start_time)` * `bookings(equipment_id, start_time)` * `equipment(status, category)` * `calibration(next_due_date)` * `audit_logs(created_at)` ### 7.6 Transaction strategy Booking creation: * Validate request. * Begin database transaction. * Insert booking. * Insert outbox event. * Commit transaction. * Return confirmation. If the booking constraint fails, the transaction rolls back. ### 7.7 Backup and recovery * Automated database backups. * Point-in-time recovery if supported by the managed database. * Periodic restoration testing. * Defined retention policies. * Documented data deletion process. ### ⚡ PHASE 8 — SCALABILITY AND PERFORMANCE ENGINEERING ### 8.1 Scaling strategy | Component | Strategy | | ---------- | ----------------------------------------- | | FastAPI | Horizontal scaling | | PostgreSQL | Query optimization and connection pooling | | Redis | Cache frequently requested equipment data | | Worker | Increase worker concurrency | | Frontend | CDN delivery | | API | Rate limiting and pagination | ### 8.2 Potential bottlenecks | Bottleneck | Trigger | Mitigation | | -------------------- | ------------------------------ | ------------------------ | | Booking conflicts | Simultaneous reservations | Database constraints | | Database connections | Too many application instances | Connection pooling | | Availability queries | Large booking history | Composite indexes | | Notifications | Provider slowdown | Background queue | | Redis hot keys | Popular equipment | TTL and key distribution | ### 8.3 Load testing Proposed tests: * 500 concurrent users. * 1,000 concurrent availability requests. * 100 simultaneous booking attempts for one equipment item and overlapping time slot. * 10,000 equipment searches. * Notification provider outage simulation. Success criteria: * No overlapping confirmed reservations. * Normal read API p95 below 300 ms under the agreed baseline load. * No unbounded worker backlog. * No unauthorized access. * No lost committed booking records. These are test targets, not achieved results. ### 🔄 PHASE 9 — DISTRIBUTED SYSTEMS AND CONSISTENCY ### 9.1 Source of truth | Data | Source of truth | | ------------------- | ------------------------------------------------------------- | | Users and roles | University identity provider plus local authorization mapping | | Equipment | PostgreSQL | | Bookings | PostgreSQL | | Maintenance | PostgreSQL | | Calibration | PostgreSQL | | Notification status | PostgreSQL | ### 9.2 Consistency model * Booking creation: Strong consistency. * Equipment updates: Strong consistency. * Maintenance updates: Strong consistency. * Notifications: Eventual consistency. * Notification delivery status: Asynchronous. ### 9.3 Outbox pattern The booking transaction writes both: * Booking record. * Notification event. A worker reads pending events and sends notifications. If the worker crashes after sending but before marking the event processed, it may send the notification again. Therefore: * Events have unique IDs. * Consumers track processed event IDs. * Notification operations use idempotency where supported. * Duplicate delivery is handled safely. Exactly-once delivery is not guaranteed. ### 9.4 Failure handling | Failure | Behavior | | -------------------------- | -------------------------------------- | | Email provider unavailable | Retry with bounded backoff | | Worker crashes | Resume pending events | | Duplicate event | Detect and ignore duplicate processing | | Database unavailable | Reject new booking operations | | Redis unavailable | Fall back to database reads where safe | ### 🔐 PHASE 10 — SECURITY AND TRUST BOUNDARIES ### 10.1 Authentication OAuth 2.0 integration with the university identity provider. Validate: * Token signature. * Issuer. * Audience. * Expiration. * Required scopes. ### 10.2 Authorization matrix | Action | Student | Professor | Admin | | ------------------ | ------- | --------- | ----- | | View equipment | Yes | Yes | Yes | | Create booking | Yes | Yes | Yes | | Cancel own booking | Yes | Yes | Yes | | Manage equipment | No | No | Yes | | Record maintenance | No | No | Yes | | Manage calibration | No | No | Yes | | View all bookings | No | Limited | Yes | Professor permissions are provisional and require business confirmation. ### 10.3 Threat analysis | Threat | Mitigation | | --------------------------- | ---------------------------------- | | Unauthorized booking access | Object-level authorization | | Token theft | Secure token handling | | SQL injection | Parameterized queries | | Privilege escalation | Server-side RBAC | | API abuse | Rate limiting | | Sensitive data exposure | Encryption and access restrictions | | Audit manipulation | Restricted audit write permissions | | Secret leakage | Managed secret storage | ### 10.4 Trust boundaries * Browser to backend. * Backend to identity provider. * Backend to PostgreSQL. * Backend to notification provider. * Administrator to privileged operations. Security testing must verify each boundary independently. ### 🛡️ PHASE 11 — RELIABILITY, RESILIENCE AND RECOVERY ### 11.1 Failure scenarios | Failure | Response | | ---------------------- | ------------------------------------------------ | | FastAPI instance crash | Load balancer routes to healthy instance | | Database outage | Stop booking writes and return controlled errors | | Redis outage | Use safe database fallback | | Worker crash | Restart and process pending events | | Notification outage | Retry with backoff | | Failed deployment | Roll back application version | | Corrupted data | Restore from verified backup | ### 11.2 Reliability controls * Health checks. * Readiness checks. * Bounded retries. * Request timeouts. * Circuit breakers for external dependencies. * Database backups. * Dead-letter handling for permanently failed events. * Graceful shutdown. ### 11.3 Recovery targets | Metric | Proposed target | | ------------ | --------------- | | Availability | 99.9% | | RTO | 2 hours | | RPO | 15 minutes | These targets require infrastructure validation and business approval. ### ☁️ PHASE 12 — DEPLOYMENT, INFRASTRUCTURE AND OPERATIONS ### 12.1 Deployment architecture * React frontend hosted through CDN. * FastAPI application deployed in Docker containers. * Managed PostgreSQL database. * Managed Redis instance. * Background notification worker. * Cloud secret manager. * Centralized monitoring. ### 12.2 Environment separation | Environment | Purpose | | ----------- | ---------------------------------- | | Development | Developer testing | | Staging | Integration and acceptance testing | | Production | Real university operations | ### 12.3 CI/CD pipeline ```mermaid flowchart LR A[Git Push] B[Lint and Unit Tests] C[Security Scan] D[Build Docker Image] E[Integration Tests] F[Staging Deployment] G[Approval] H[Production Deployment] I[Health Verification] A --> B --> C --> D --> E --> F --> G --> H --> I ``` ### 12.4 Release safety * Version-controlled migrations. * Backward-compatible schema changes. * Health checks before traffic routing. * Rollback plan. * Production approval. * Database migration verification. ### 📈 PHASE 13 — OBSERVABILITY AND VALIDATION STRATEGY ### 13.1 Metrics | Metric | Purpose | | ------------------------- | ---------------------- | | API latency p95/p99 | Performance | | HTTP 5xx rate | Application failures | | Booking conflict rate | Reservation contention | | Database connection usage | Database capacity | | Redis hit rate | Cache effectiveness | | Queue depth | Notification backlog | | Notification failure rate | Delivery health | | Calibration overdue count | Business compliance | ### 13.2 Logging Every request should include: * Request ID. * Timestamp. * Operation. * Response status. * Processing duration. Avoid logging: * Access tokens. * Passwords. * Sensitive personal data. * Full authentication headers. ### 13.3 Alerting | Alert | Response | | --------------------------- | -------------------------------- | | API errors increase | Investigate application logs | | Database unavailable | Escalate immediately | | Queue backlog grows | Inspect worker and provider | | Calibration deadline missed | Notify lab administrator | | High booking conflict rate | Investigate concurrency behavior | ### 13.4 Testing strategy * Unit tests. * API contract tests. * Integration tests. * Database concurrency tests. * Load tests. * Security tests. * Backup restoration tests. * Failure-injection tests. ### 📝 PHASE 14 — ARCHITECTURE DECISION RECORDS ### ADR-001: Modular Monolith Context: Moderate initial workload and transactional booking requirements. Decision: Use a modular monolith. Alternatives: Microservices, serverless architecture. Advantages: * Lower operational complexity. * Easier transaction management. * Faster initial implementation. Disadvantages: * Independent scaling is limited. * Modules share deployment lifecycle. Reversal condition: Independent scaling or deployment becomes a measurable requirement. ### ADR-002: PostgreSQL Decision: Use PostgreSQL as the primary database. Rationale: Relational integrity, transactions, and range exclusion constraints. Alternative: MongoDB. Trade-off: Relational schema migrations require discipline. Reversal condition: A distinct workload demonstrates that another datastore is necessary. ### ADR-003: REST API Decision: REST with JSON. Rationale: Straightforward resource-oriented workflows. Alternative: GraphQL. Reversal condition: Complex client-specific data aggregation becomes a significant requirement. ### ADR-004: Asynchronous Notifications Decision: Use a transactional outbox and background worker. Rationale: Booking success must not depend on notification provider availability. Alternative: Synchronous notification delivery. Trade-off: Notification delivery is delayed and eventually consistent. Reversal condition: Notification requirements change substantially. ### ⚠️ PHASE 15 — RISK REGISTER AND IMPLEMENTATION ROADMAP ### 15.1 Risk register | Risk ID | Risk | Trigger | Impact | Mitigation | Validation | | ------- | ----------------------- | ---------------------- | ------ | ------------------------------ | ------------------- | | R01 | Double booking | Concurrent requests | High | DB exclusion constraint | Concurrency tests | | R02 | Database outage | Infrastructure failure | High | Backups and recovery | Restore drill | | R03 | Unauthorized access | Permission flaw | High | RBAC and ownership checks | Security tests | | R04 | Notification backlog | Provider outage | Medium | Retry and dead-letter handling | Failure simulation | | R05 | Calibration missed | Scheduler failure | High | Monitoring and reconciliation | Scheduled-job tests | | R06 | Performance degradation | Traffic growth | Medium | Profiling and scaling | Load tests | ### 15.2 Implementation roadmap | Stage | Task | Deliverable | Acceptance criteria | | ----- | ------------- | ----------------------- | ------------------------ | | 1 | Foundation | FastAPI and React setup | Application runs | | 2 | Identity | OAuth integration | Valid token required | | 3 | Equipment | Inventory module | Equipment CRUD works | | 4 | Booking | Reservation module | Overlap prevented | | 5 | Maintenance | Maintenance module | Equipment status managed | | 6 | Calibration | Calibration module | Due dates tracked | | 7 | Notifications | Worker and outbox | Events processed safely | | 8 | Security | RBAC and audit | Access tests pass | | 9 | Operations | Monitoring and backups | Recovery tested | | 10 | Launch | Production deployment | Release checklist passed | ### 15.3 Engineering ownership * Backend engineers: APIs and domain logic. * Database engineer: schema, indexes, migrations. * Frontend engineers: React application. * DevOps engineer: deployment and monitoring. * Security reviewer: identity and authorization. * QA engineer: functional and concurrency testing. Precise delivery dates require team capacity and project estimation. ### 🎯 PHASE 16 — FINAL PRINCIPAL ARCHITECTURE PACKAGE ### 16.1 Final architecture recommendation ### Recommended technology architecture Frontend React Backend FastAPI Primary database PostgreSQL Cache Redis Background processing Worker + Outbox Authentication OAuth 2.0 Deployment Docker + Managed Cloud ### 16.2 Final unresolved decisions * Booking approval requirements. * Maximum reservation duration. * Professor priority rules. * Maintenance cancellation policies. * Calibration record retention. * SMS provider selection. * Final cloud provider. * Production backup and recovery configuration. ### 16.3 Architecture consistency review | Review area | Result | | ------------------------ | --------------------------- | | Requirements and modules | Consistent | | API and database | Consistent | | Booking concurrency | Database-enforced | | Notifications | Asynchronous | | Security and permissions | Defined, pending validation | | Deployment | Defined | | Recovery | Targets proposed | | Capacity | Assumption-based | | Production evidence | Not yet available | Not production approved The architecture is a blueprint. Production approval requires implementation, testing, security review, load validation, and recovery evidence. ### 16.4 Definition of Done Architecture approval requires: * All critical business requirements documented. * All unresolved business rules assigned. * API contracts reviewed. * Database schema approved. * Concurrent booking tests passed. * Authorization tests passed. * Backup restoration verified. * Load tests meet agreed objectives. * Notification failure recovery verified. * Monitoring and alerts operational. * Deployment rollback tested. * Security review completed. * Architecture decision records approved. ✅ Sample Test 1 completed — All 16 phases covered. Overall test assessment * Requirements reconstruction: Covered. * Workload calculations: Covered. * Architecture alternatives: Compared. * Five architecture diagrams: Provided. * API and database contracts: Provided. * Scalability and distributed systems: Covered. * Security and reliability: Covered. * Deployment and observability: Covered. * ADRs and risk register: Provided. * Implementation roadmap: Provided. * Definition of Done: Provided. Important testing observation: The prompt successfully produces an end-to-end architecture blueprint, but a senior engineering review should challenge the assumptions, validate PostgreSQL concurrency behavior, and verify that all diagrams, API contracts, and deployment decisions match the final requirements.