POS Gateway - Signals

Location: api/nextango/apps/pos_gateway/ (no signals.py) Last Updated: 2026-07-09

Overview

POS Gateway has no signals.py. This is deliberate, not an oversight.

The gateway is an infrastructure domain, not a business domain. It provides REST and WebSocket endpoints, session management, and orchestration, but it doesn't own the business data that would need signal handlers. Transactions, products, and users are owned by their respective domains, and those domains' own signal handlers (Sanity sync, cache invalidation) still fire normally when the gateway calls into them.

What Triggers Real-Time Behavior Instead

Where a business domain might use a post_save signal to react to a model change, POS Gateway uses explicit calls: a gateway service completes its delegated call to a domain service, checks the result, and explicitly calls WebSocketBroadcaster (see Broadcast Utilities) to notify connected terminals. The broadcaster's production callers are the transactions app's own signal handlers, not gateway services: TransactionGatewayService.process_payment() never references WebSocketBroadcaster; on a completed payment it calls InventoryAdjustmentService.commit_reserved_inventory(), and the completion broadcast fires from the transactions domain (see Broadcast Utilities).

This is explicit rather than reactive because broadcasting needs store and terminal context that a model-level signal handler doesn't have, and because the gateway wants control over exactly when a broadcast fires relative to the rest of the request.

In practice, most WebSocketBroadcaster calls originate from the transactions domain's own post_save signal handler on SaleTransaction and Return (transactions/signals.py), not from a pos_gateway service. The transactions app owns the signal; it calls into the gateway's broadcaster as its side effect. This is the pattern the rest of this page describes: the domain that owns the data owns the signal, and the gateway is called into rather than reacting on its own.

Gateway Models Have No Signals

TerminalSession, InventoryReservation, ManagerApprovalRequest, and GatewayPerformanceMetric (see Models) are all managed by explicit service calls rather than reactive signal handlers. Session creation, approval decisions, and reservation lifecycle are driven by the service layer directly, not by post_save or pre_save hooks on these models.

Was this page helpful?