Architectural Design and Engineering Analysis of an Enterprise Point-of-Sale and Inventory Management System Utilizing Advanced Object-Oriented Patterns in Python, Flask, and MySQL

1. Introduction

1.1 Background and Context

Point-of-Sale (POS) systems represent a fundamental operational software category responsible for recording transaction data, processing tender payments, and adjusting inventory balances in real time1. Within Small and Medium Enterprises (SMEs), these operational logs provide critical analytical insights into revenue velocity, product demand, tax liabilities, and employee accountability1. While commercial off-the-shelf POS software platforms exist, they frequently impose recurring licensing fees, rely on proprietary cloud infrastructures, and package overly complex feature sets tailored for large enterprise retail chains1. A self-hosted, domain-focused web application serves as an effective alternative, providing SMEs with full data ownership while serving as an ideal platform for demonstrating modern software engineering principles1.

1.2 Problem Statement

Retail operations in small enterprises are traditionally managed using physical paper receipts, disjointed spreadsheets, or informal memory-based tracking1. This reliance on uncoordinated manual processes introduces severe systemic vulnerabilities1:

• Stock Drift and Loss: Discrepancies between recorded inventory levels and physical shelf counts accumulate over time, resulting in stockouts or unrecorded inventory shrinkage1.

• Pricing and Ledger Mismatches: Hand-calculated taxes, ad-hoc discounts, and manual arithmetic introduce ledger inaccuracies and financial loss1.

• Audit and Governance Deficits: Cashier activities, pricing alterations, and refund requests lack identity attribution, leaving business owners unable to verify transaction history or detect insider fraud1.

• Concurrency Conflicts: Simultaneous sales across multiple checkout counters frequently cause over-selling or negative inventory counts due to delayed stock updates1.

1.3 Project Objectives

To resolve these operational challenges, this project engineered a web-based POS and inventory management system designed around clean software architecture and object-oriented principles1. The implementation was evaluated against five key technical and functional milestones1.

Objective Area	Target Success Criterion	Implementation Status	Empirical Evidence
Authentication & RBAC	Support secure login/logout, Bcrypt password hashing, email OTP verification, three distinct user roles, and enforce route protection returning HTTP 403 on authorization failure1.	Achieved	Implemented via Flask-Bcrypt, Flask-Mailman OTP workflows, dynamic role_permissions database checks, and explicit route decorators1.
Clean OOP Layering	Establish at least 5 domain classes, 3 service managers, and 3 repository classes enforcing Single Responsibility Principles1.	Achieved	Codebase contains 9 domain model classes, 3 core services plus specialized report exporters, and 6 abstract-derived repositories1.
Relational Database Design	Formulate an Entity-Relationship Diagram (ERD), a relational schema with foreign keys and validation constraints, and seed scripts1.	Achieved	Schema composed of 14 relational tables featuring foreign key cascades/nullifications and strict CHECK constraints1.
Core POS Business Logic	Deliver complete CRUD for products/categories, terminal checkout supporting configurable tax/discounts/payments, full refunds, and reporting1.	Achieved	Full suite of product management tools, single-transaction POS engine, invoice refund tracking, and CSV/JSON reporting exporters1.
Automated Verification	Develop at least 10 automated unit and integration tests verifying domain rules and access control protocols1.	Achieved	10 automated pytest cases executing domain model validation, RBAC boundaries, and staging workflows1.

1.4 Scope and Limitations

The functional boundaries of the application focus on core store workflows1. In-scope capabilities include email OTP registration verification, multi-role authorization across three system roles (Admin, Stock Manager, Cashier), full product catalog CRUD operations, manual stock movement logging, a web-based POS terminal supporting cash and card sales, configurable tax and service charge rates, single-refund invoice processing, and financial reporting with CSV and JSON exports1.

External payment gateway processing (e.g., credit card terminal APIs), physical receipt printer drivers, barcode scanner hardware protocols, multi-branch multi-store networking, partial line-item refunds, and cloud deployment scripts are explicitly out of scope for this initial release1.

2. Literature Review and Technical Foundations

2.1 Architectural Patterns in Web Application Engineering

Modern web application design emphasizes the separation of concerns to maximize testability, maintainability, and code reusability2. The Model-View-Controller (MVC) design pattern isolates data models and business rules from the user interface rendering layer2. In complex enterprise applications, pure MVC can result in bloated controller classes that mix HTTP parsing with core domain logic2. To prevent this architectural anti-pattern, modern software engineering advocates multi-tier layered topologies—specifically separating data access (Repositories) and business orchestration (Services) from HTTP handlers (Routes/Controllers)1.

2.2 Object-Oriented Design Patterns

Design patterns provide standardized, reusable solutions to recurring software engineering challenges4. In object-oriented application development, the Gang of Four (GoF) design patterns are categorized into Creational, Structural, and Behavioral patterns4:

• Strategy Pattern: Defines a family of algorithms, encapsulating each one, and making them interchangeable at runtime4. This pattern is widely applied in billing, pricing, and payment processing engines1.

• Template Method Pattern: Defines the skeleton of an algorithm in a base class method, deferring specific primitive steps to subclasses4. This enables consistent execution flows across different format exporters (e.g., JSON and CSV generation)1.

• Factory Pattern: Abstracts object creation logic, ensuring that complex initialization and validation checks are executed in a centralized factory method4.

• Repository Pattern: Mediates between the domain mapping layer and data mapping layers using a collection-like interface for accessing domain objects, isolating raw SQL or ORM queries1.

2.3 Database Concurrency and Pessimistic Locking

In multi-user transactional web systems, concurrent access to shared resources introduces severe race conditions7. Concurrency control strategies are broadly divided into optimistic and pessimistic concurrency models7:

• Optimistic Concurrency Control: Assumes resource conflicts are rare and verifies data consistency at transaction commit time (e.g., using version checks)7. If a conflict occurs, the transaction is aborted and rolled back7.

• Pessimistic Concurrency Control: Assumes resource contention will occur and acquires strict locks on target rows when data is first read7. In SQL systems, pessimistic locking is implemented via SELECT ... FOR UPDATE constructs within an explicit ACID transaction block1. This forces concurrent threads to wait until the lock is released, preventing double-spend and over-allocation defects in inventory checkouts1.

3. System Architecture and Technological Stack

3.1 Technology Stack Specifications

The software stack was chosen to provide execution efficiency, strict data typing, robust relational constraints, and clean object orientation1.

Technology Component	Version / Package	Domain Role and Responsibility
Runtime Language	Python 3.12 / 3.13	Primary programming language; utilizes native type hints, Abstract Base Classes (abc), and dataclasses1.
Web Framework	Flask 3.x	Lightweight Web Server Gateway Interface (WSGI) framework utilizing application factories and Blueprints1.
Database Engine	MySQL 8.0	Relational storage engine providing ACID transactions, foreign key constraints, and row-level pessimistic locking1.
Database Driver	mysql-connector-python 9.x	Database connectivity provider configured with a connection pool size of 51.
Authentication Tools	Flask-Bcrypt 1.0+	Hashing engine applying adaptive salted Bcrypt algorithms for credential security1.
Messaging Service	Flask-Mailman 1.1+	SMTP mail dispatch engine connecting to Gmail SMTP services for OTP transmission1.
Configuration	python-dotenv 1.0+	Environment isolation module reading .env files for database keys and mail credentials1.
Testing Harness	Pytest 8.x	Test runner executing automated domain logic, model constraint, and authorization checks1.

3.2 Layered Architectural Topology

The application enforces a five-tiered layered architecture, maintaining a single directional request flow1:

1. Presentation Layer (Jinja2 HTML Templates): Renders dynamic web pages, adapting navigation elements based on active user role permissions1.

2. Controller/Route Layer (Flask Blueprints): Handles HTTP requests, extracts parameters, evaluates authentication/permission decorators, delegates work to services, and formats responses1.

3. Application Service Layer (Business Domain Services): Implements business workflows, manages strategy selection, calculates invoice financial totals, and coordinates transactions1.

4. Data Access Repository Layer: Encapsulates parameterised SQL queries, mapping database rows to strongly typed Python model entities1.

5. Database Storage Layer (MySQL Engine): Persists relational tables, enforcing foreign keys, unique constraints, check constraints, and row-level locks1.

4. Advanced Object-Oriented Software Design

4.1 Implementation of OOP Paradigms

The codebase incorporates key object-oriented paradigms to promote modularity and prevent invalid state assignment1.

OOP Concept	Domain Implementation Mechanics	Architectural Rationale
Encapsulation & Validation Properties	Implemented in Product.sku, Product.price, Product.quantity, User.username, and User.email using Python @property setters1.	Setter methods intercept attribute assignments, automatically casting formats (e.g., stripping whitespace, enforcing uppercase SKUs) and rejecting invalid domain states (e.g., negative prices or costs) at runtime1.
Dataclass Abstraction	Domain entities (User, Product, Category, Sale, SaleItem) use Python @dataclass. Immutability is enforced via frozen=True on value objects like Receipt, StockMovement, and Permission1.	Eliminates boilerplate initializer code while guaranteeing that transactional records, such as issued receipts and historical audit movements, cannot be mutated after creation1.
Abstraction via ABC	Abstract Base Classes defined via abc.ABC and @abstractmethod decorators for DiscountStrategy, PaymentStrategy, BaseRepository, and ReportExporter1.	Formally establishes software contracts that mandate concrete subclasses implement essential signatures, preventing runtime interface mismatch errors1.
Polymorphism & Strategy Pattern	SaleService.checkout() delegates discount calculations and payment execution to abstract strategy objects1.	Decouples transaction orchestration from specific pricing or payment implementations, allowing new strategy types to be added without modifying the core checkout engine1.
Template Method Pattern	Base ReportExporter.export() method implements a fixed processing pipeline (filtering, data normalization) while delegating formatting to abstract serialize() methods in JsonReportExporter and CsvReportExporter1.	Prevents code duplication across file generation endpoints while ensuring consistent output formatting across different reporting contexts1.
Factory Pattern	Encapsulated within UserFactory.create()1.	Provides a centralized instantiation point that evaluates assigned role strings, validates email formats, applies default permissions, and instantiates valid User objects1.
Composition over Inheritance	SaleService encapsulates explicit references to SaleRepository and ProductRepository instances rather than extending repository bases1.	Facilitates loose coupling, simplifies mock object injection during unit testing, and enforces strict operational boundaries between services and data access code1.
Special Method Overloading	Dunder methods implemented across models, including __eq__ and __hash__ in Product (keyed on SKU), __len__ in Sale (returning item counts), and __getitem__ in domain collections1.	Enables intuitive native Python syntax operations on complex domain entities, such as set operations on product instances and direct indexing on sales objects1.
Generic Collections	Type-hinted wrappers (EntityCollection[T], ProductCollection, SaleCollection)1.	Wraps domain entity lists in object containers to provide domain-specific filtering, lookup methods, and aggregation capabilities1.
Decorator Mechanics	Custom route decorators (@require_login, @require_permission, @require_any_permission, @log_action)1.	Separates cross-cutting concerns (authentication checks, role authorization, audit trail logging) from primary HTTP request controllers1.

4.2 Structural and Behavioral Design Patterns

Strategy Pattern for Discounts and Payments

The checkout pipeline delegates calculation tasks to strategy classes implementing abstract interfaces1. DiscountStrategy mandates a calculate_discount(subtotal) method1. Concrete classes include NoDiscount, PercentageDiscount, FixedDiscount, and VIPDiscount1. PaymentStrategy abstracts tender settlement, where CashPayment calculates change due and CardPayment verifies authorization coverage1.

Template Method Pattern for Report Exporters

ReportExporter implements a unified export(report_data) template method1. This method normalizes raw model collection data into standard tabular key-value dictionaries before delegating file formatting to abstract serialize() implementations in JsonReportExporter and CsvReportExporter1.

5. Database Architecture, Snapshotting, and Concurrency Engineering

5.1 Schema Architecture and Entity Relationships

The relational schema comprises 14 tables categorized into four domain modules1:

• Identity Module: users, roles, permissions, user_roles, role_permissions, otp_tokens1.

• Catalog Module: categories, products, stock_movements, sale_reservations1.

• Sales Module: sales, sale_items, refunds1.

• System Module: app_settings, activity_logs1.

Table Name	Primary / Unique Keys	Foreign Key Relationships	Enforced Constraints & Logic
users	id (PK), username (UQ), email (UQ)	N/A	Active account status flag; mandatory salted hash password storage1.
roles	id (PK), name (UQ)	N/A	Restricted to baseline system roles: Admin, Stock Manager, Cashier1.
permissions	id (PK), name (UQ)	N/A	Enforces dot-notation permission identifiers (e.g., product.manage)1.
user_roles	(user_id, role_id) (Composite PK)	user_id -> users.id (CASCADE), role_id -> roles.id (CASCADE)	Cascade deletion ensures clean account removal without orphan records1.
role_permissions	(role_id, permission_id) (Composite PK)	role_id -> roles.id (CASCADE), permission_id -> permissions.id (CASCADE)	Dynamic runtime permission mapping table1.
categories	id (PK), name (UQ)	N/A	Product classification entity1.
products	id (PK), sku (UQ)	category_id -> categories.id (SET NULL)	CHECK (price >= 0), CHECK (quantity >= 0), CHECK (reorder_level >= 0)1.
stock_movements	id (PK)	product_id -> products.id (CASCADE), user_id -> users.id (SET NULL)	CHECK (quantity_change <> 0); tracks movement types (IN, OUT, SALE, REFUND)1.
sale_reservations	id (PK), reservation_token (UQ)	product_id -> products.id (CASCADE)	CHECK (quantity > 0); automated 15-minute expiration timestamp tracking1.
sales	id (PK), invoice_number (UQ)	cashier_id -> users.id (RESTRICT)	Immutable snapshots of active tax rates and extra charge settings1.
sale_items	id (PK)	sale_id -> sales.id (CASCADE), product_id -> products.id (RESTRICT)	CHECK (quantity > 0), CHECK (unit_price >= 0); snapshots unit price and cost1.
refunds	id (PK), sale_id (UQ)	sale_id -> sales.id (RESTRICT), refunded_by -> users.id (RESTRICT)	Unique constraint on sale_id enforces a strict 1:1 single-refund limit1.
activity_logs	id (PK)	user_id -> users.id (SET NULL)	Captures actor ID, HTTP endpoint, status code, and sanitized JSON details1.

5.2 Immutable Financial Snapshotting

To guarantee that past financial records remain accurate despite future product price changes or tax adjustments, the system executes immutable financial snapshotting during checkout1:

• sales.tax_rate and sales.extra_charges persist active store tax settings at transaction time1.

• sale_items.unit_price and sale_items.unit_cost persist unit retail prices and wholesale costs at the exact moment of sale1.

Financial invoice line totals, sub-totals, tax additions, and final totals are calculated using exact decimal arithmetic:

5.3 Concurrency Control Mechanisms

To prevent race conditions during concurrent checkouts across multiple cashiers, the application combines short-term tokenized cart reservations with database pessimistic row locking1:

Short-Term Cart Reservations

Adding items to a terminal cart reserves stock in sale_reservations for 15 minutes1. Available stock for other terminals is calculated dynamically:

Pessimistic Row Locking

During transaction execution, SaleRepository.create_atomic() opens a transaction block and executes SELECT ... FOR UPDATE across target product rows1. This acquires exclusive row locks in MySQL, forcing concurrent transactions targeting the same products to wait until the holding transaction issues a COMMIT or ROLLBACK1.

6. System Security, Authorization, and Audit Infrastructure

6.1 Authentication and Identity Management

User authentication uses salted password hashing via Flask-Bcrypt1. New account registration implements a multi-step verification pipeline1:

1. Registration details submitted via POST /auth/register are validated and held in staging memory1.

2. A random six-digit OTP is generated, converted into a SHA-256 digest, and stored with a 10-minute expiration window1.

3. The plain six-digit code is dispatched to the user's email address using Flask-Mailman1.

4. Upon submitting the matching OTP via POST /auth/verify, the digest is confirmed and the user record is committed to the database1.

6.2 Role-Based Access Control (RBAC)

Access control is governed by ten system permissions mapped across three default roles1:

System Permission Identifier	Admin Role	Stock Manager Role	Cashier Role
user.manage	Allowed	Denied	Denied
role.manage	Allowed	Denied	Denied
product.read	Allowed	Allowed	Allowed
product.manage	Allowed	Allowed	Denied
stock.adjust	Allowed	Allowed	Denied
pos.checkout	Allowed	Allowed	Allowed
sale.refund	Allowed	Allowed	Allowed
report.financial	Allowed	Denied	Denied
report.inventory	Allowed	Allowed	Denied
report.shift	Allowed	Denied	Allowed

Permissions are evaluated dynamically on every HTTP request via custom decorators (@require_permission), returning HTTP 403 Forbidden when access is denied1.

6.3 Audit Logging and Input Sanitization

The @log_action decorator automatically writes request metadata to activity_logs1. Sensitive fields (such as password, otp, card_number) are redacted from the request payload before JSON serialization1. All SQL operations use parameterized queries (%s), preventing SQL injection attacks1.

7. Empirical Evaluation, Software Defect Analysis, and Vulnerabilities

7.1 Automated and Manual Verification Results

Automated testing was executed via pytest, achieving a 100% pass rate across 10 unit test cases1.

Test Suite Module	Target Components	Verified Invariants & Domain Rules	Execution Result
tests/test_models.py	User, Product, SaleItem	Verifies username/email string normalization; confirms rejection of negative product prices and negative costs; permits missing cost and untracked stock flags; enforces non-zero purchase quantities on sale lines1.	5 Passed
tests/test_rbac.py	RBAC rules & route protection	Verifies default permission assignments (Admin manages users; Stock Manager manages inventory; Cashier executes checkout); confirms HTTP 403 Forbidden response on unauthorized endpoint requests1.	2 Passed
tests/test_registration_flow.py	AuthService, registration logic	Confirms password hashing during account staging; verifies account creation occurs only upon correct OTP submission; rejects incorrect OTP attempts; verifies clear error responses when SMTP mail is unconfigured1.	3 Passed

Manual workflow testing verified eight core user interaction scenarios1:

Case #	Operational Test Scenario	Target Execution Workflow	Expected System Outcome
1	Role Authentication	Authenticate as Admin, Stock Manager, and Cashier roles sequentially1.	Sidebar navigation dynamically renders links matching authenticated role permissions1.
2	Catalog CRUD	Admin creates category and product, followed by SKU and name searches1.	Product renders correctly in catalog tables and responds to search queries1.
3	Stock Movement	Perform inventory stock adjustment (IN), followed by oversized decrease (OUT)1.	Stock IN increases quantity; stock OUT exceeding available inventory is rejected1.
4	Terminal Checkout	Add product to POS cart, apply discount, record cash payment, submit sale1.	Transaction writes receipt showing tax and change; stock decreases; sale appears in history1.
5	Refund Execution	Issue full invoice refund with reason code; attempt second refund on same sale1.	Stock restored; movement logged; second refund attempt rejected by 1:1 constraint1.
6	Role Modification	Admin modifies an active user's assigned role during an active session1.	User's navigation links and route permissions update immediately on next request1.
7	Report Access	Request financial, inventory, and shift reports across all three user roles1.	Admin views all reports; Stock Manager views inventory; Cashier views shift report only1.
8	Cart Concurrency	Open identical product in POS checkout carts across two distinct terminal sessions1.	Reservation engine updates available stock display in second terminal cart in real time1.

7.2 Root-Cause Analysis of Eager Strategy Instantiation Defect

System testing identified a bug where entering a fixed discount greater than $100.00 raises an unhandled exception1.

Defect Mechanics

SaleService.checkout() eagerly instantiates all strategy classes before evaluating the requested discount type1:

Python

# Eager Instantiation Defect in SaleService.checkout()
def checkout(self, sale_data, discount_type, discount_value):
    no_discount = NoDiscount()
    pct_discount = PercentageDiscount(discount_value)  # Raises ValueError if discount_value > 100
    fixed_discount = FixedDiscount(discount_value)
   
    strategy_map = {
        "none": no_discount,
        "percentage": pct_discount,
        "fixed": fixed_discount
    }
    selected_strategy = strategy_map.get(discount_type)

When a user submits a valid fixed discount of $150.00, PercentageDiscount(150) executes during eager instantiation, validating that percentage values satisfy 1. This raises an exception before the code can select fixed_discount1.

Remediated Design

The issue is resolved by implementing lazy factory evaluation:

Python

# Refactored Lazy Factory Construction
STRATEGY_FACTORIES = {
    "none": lambda val: NoDiscount(),
    "percentage": lambda val: PercentageDiscount(val),
    "fixed": lambda val: FixedDiscount(val)
}

def checkout(self, sale_data, discount_type, discount_value):
    factory = STRATEGY_FACTORIES.get(discount_type)
    if not factory:
        raise ValueError(f"Unsupported discount strategy: {discount_type}")
    selected_strategy = factory(discount_value)

7.3 Vulnerability Assessment

1. Volatile Memory Staging: Pending registrations and OTP digests are stored in process memory, causing loss of staging state upon server restarts1.

2. CSRF Protection: State-changing requests rely on SameSite=Lax cookies; anti-CSRF tokens should be added prior to production1.

3. Service Test Coverage: Automated tests focus primarily on domain models; integration testing should be expanded to cover SaleService and transactional repository routines1.

8. Conclusion

This project successfully designed and evaluated a Point-of-Sale and Inventory Management System tailored for SMEs1. By organizing the codebase into Model, Repository, Service, and Route layers, the application enforces a clean separation of concerns1. Object-oriented design patterns—including Strategy, Template Method, and Factory patterns—were applied to decouple complex business rules1. Database-level pessimistic locking and immutable snapshotting ensure data integrity and financial precision during concurrent multi-terminal checkouts1. Addressing identified strategy construction defects and expanding automated integration tests will further prepare this system for enterprise commercial deployment1.

References

1. SME POS Project Development Team. (2024). SME Point-of-Sale and Inventory Management System Technical Documentation. Final Project Report, Advanced Object-Oriented Programming with Python1.

2. Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley1.

3. Leff, A., & Rayfield, J. T. (2001). Web-application development using the Model/View/Controller design pattern. Proceedings Fifth IEEE International Enterprise Distributed Object Computing Conference, 118–1273.

4. IEEE Computer Society. (2023). Employing MVC-based design patterns and multi-tier architectural strategies for web application development. IEEE CISES Proceedings, 1–62.

5. IEEE Software Engineering Group. (2022). Evaluation of Creational and Behavioral Design Patterns in Web and Distributed Systems. IEEE IC3I Proceedings, 10–165.

6. Database Systems & Distributed Infrastructure Research. (2023). Concurrency Control, Row-Level Locking, and Transaction Isolation in Multi-User Relational Systems7.

Post-Report Required Completion Checklist for Project Submission

The following checklist details missing project metadata identified during document parsing. These placeholders must be completed prior to submitting the final paper:

1. Semester / Year Placeholder (Section 1 Title Block): Update the project cover block with the current academic period (e.g., Semester I, 2024–2025)1.

2. Field Observation / Interview Notes (Section 1.2): Insert empirical field observation notes or shop interview details gathered during initial requirements gathering1.

3. User Interface Screenshots (Section 4.8): Embed verified application screenshots depicting:

• Login & OTP Verification View

• Product Catalog Management Table

• Active POS Terminal with Cart Items

• Issued Receipt View

• Sales History & Refund View

• Financial & Shift Reporting Dashboards

• Administration Users & Roles Control Panel1.

4. Manual Test Execution Log (Section 5.2): Record Pass/Fail execution statuses and attach supporting screenshots for manual test scenarios 1 through 81.

5. Team Member Contribution Matrix (Appendix B): Complete the team contribution breakdown using assigned team member names (Phengmeng Visal, Sansokthy Reach, Line William, Pheap Pheasothearum)1:

• Line William: [Assign primary role, e.g., Systems Analyst / Project Lead, and list specific modules/commits]1

• Sansokthy Reach: [Assign primary role, e.g., Backend & OOP Designer, and list specific modules/commits]1

• Phengmeng Visal: [Assign primary role, e.g., Database Architect & Integration Lead, and list specific modules/commits]1

• Pheap Pheasothearum: [Assign primary role, e.g., UI Developer & QA Testing Lead, and list specific modules/commits]1

6. Version Control Evidence (Appendix C): Attach commit history logs or pull request statistics demonstrating collaborative development across all team members1.

Works cited

1. Exploring Modern Design Patterns within the MVC Framework, https://ieeexplore.ieee.org/iel7/10183385/10182405/10183582.pdf

2. Web-application development using the Model/View/Controller, https://ieeexplore.ieee.org/document/950428/

3. Software design pattern - Wikipedia, https://en.wikipedia.org/wiki/Software_design_pattern

4. Software design pattern on the Edge - IEEE Xplore, https://ieeexplore.ieee.org/iel7/9987724/9987729/09987912.pdf

5. Design patterns in software development - ResearchGate, https://www.researchgate.net/publication/252028814_Design_patterns_in_software_development

6. Pessimistic vs Optimistic Locking - ByteByteGo, https://bytebytego.com/guides/pessimistic-vs-optimistic-locking/

7. A Systematic Literature Review - Design Patterns - ResearchGate, https://www.researchgate.net/publication/339257854_Software_Design_Patterns_Recommendation_A_Systematic_Literature_Review

8. Software Engineering and Design Patterns Research Guide, https://papersflow.ai/research/topics/software-engineering-and-design-patterns

9. Master Database Concurrency: Pessimistic vs. Optimistic Locking, https://medium.com/@mriduaayu123/master-database-concurrency-pessimistic-vs-optimistic-locking-1476b133381f

10. Pessimistic Concurrency Control (Locking) - SAP Help Portal, https://help.sap.com/docs/abap-cloud/abap-rap/pessimistic-concurrency-control-locking

11. Software Design Patterns and Architecture Patterns –A Study Explored, https://ieeexplore.ieee.org/document/10073279/