Architectural Design of Modern Cloud-Based POS Systems

Generation 1 (1980–2000): Standalone Hardware

Traditional cash registers → Custom hardware POS (NCR, Fujitsu). Characteristics: Closed systems (no extensibility), Standalone (no network dependency), Local storage (database on device), High hardware cost (£5,000–20,000 per unit).

Generation 2 (2000–2010): Client-Server Networks

Central server (on-premises) ← Local terminals. Characteristics: Network-dependent (local LAN), Centralized data (server on-site), High operational cost (IT staff, server maintenance), Limited scalability.

Generation 3 (2010–Present): Cloud SaaS

Global cloud infrastructure ← Multi-tenant SaaS. Characteristics: Internet-based (location-agnostic), Centralized data (cloud provider manages), Minimal operational cost, Unlimited scalability, Regulatory complexity (multi-jurisdiction data residency).

Definition: Multiple customers (tenants) share the same application and infrastructure while their data remains logically isolated.

Tenancy Models:

• Model 1: Shared Database, Shared Schema — All tenants in 1 database, isolation via tenant_id columns. Pros: Cost-efficient. Cons: Complex isolation, risk of data leakage.
• Model 2: Shared Database, Separate Schemas — All tenants in 1 database, separate schema per tenant. Pros: Good performance, moderate isolation. Cons: Schema migration complexity.
• Model 3: Separate Databases — Each tenant has own database. Pros: Explicit isolation, easy audits. Cons: High operational cost.

Recommendation for POS: Model 2 (shared database, separate schemas) for balance of cost, performance, and security.

Microservices approach with separation of concerns:

• Transaction Service — Process sales, issue refunds, manage payments
• Inventory Service — Track stock, stock alerts, reorder flow
• Tax Service — Calculate tax, file reports, compliance
• Auth Service — User login, JWT tokens, role-based access control
• Reporting Service — KPI dashboard, analytics, export data
• Compliance Service — Audit trail, GDPR handling, data retention

Benefits: Separation of concerns, independent scaling, technology diversity. Trade-offs: Network latency, distributed transaction complexity, operational overhead.

Publish-Subscribe pattern for asynchronous operations. Transaction Service publishes 'transaction.completed' event → multiple services subscribe (Inventory Service decrements stock, Tax Service records tax, Reporting Service updates dashboard). Benefits: Decoupling (services don't know about each other), Asynchronous (slow services don't block), Resilience (if one fails, others continue), Scalability (easy to add new subscribers). Implementation: Message broker (RabbitMQ, Kafka, AWS SQS).