Operational problem
Keep transaction capture working when a store could not reach the central system.
Operating sites needed a dependable transaction path without treating a temporary connectivity failure as a reason to stop work. Central operations also needed consistent configuration and an end-of-day path into the central database.
Users and constraints
Local continuity across a connected office, call center, and retail network.
- Each retail store operated three to five registers and its own commercial LED sign.
- Store users needed a straightforward transaction-capture interface and reliable peripheral behavior.
- Transactions had to remain available locally when central connectivity was unavailable.
- Central configuration needed to remain managed rather than drifting independently at each site.
- End-of-day synchronization had to move recorded activity into the central database.
- The call center coordinated dispatch and collection pickup through an Access database and needed multiple workstations to submit fax requests through one shared service.
- Routed site-to-site VPN connectivity had to let central systems reach connected stores.
How I framed the problem
Separate the local transaction path from the central synchronization path.
The key requirement was continuity: capture the transaction locally first, protect the local record, and treat synchronization as a later network operation. That boundary kept a temporary connection failure from stopping store work while preserving one central data destination and configuration authority.
How the system worked
Store-and-forward behavior over one connected operating network.
Corporate office
Central configuration, transaction database, synchronization, administration, and cross-site support.
Retail stores
Three to five registers per location, protected local transaction files, offline continuity, and end-of-day synchronization.
Call center
Dispatch and collection-pickup coordination using a shared Access database.
Shared fax service
A custom Windows service accepted fax requests from multiple Access workstations.
Store peripherals
Custom peripheral drivers, register devices, telephony, and one vendor LED sign at each store.
Protected local file-based storage provided the continuity boundary, but no specific encryption algorithm is claimed. The system focused on transaction capture; inventory-management behavior is not attributed to it. Commercial LED signage was integrated as a vendor system rather than custom display hardware.
What I owned
Developed the software stack and carried it through site deployment.
- Visual Basic
- Visual Studio
- Microsoft Access
- Windows services
- Peripheral drivers
- Site-to-site VPN
How I tested it
Connectivity loss was an operating condition, not an afterthought.
I tested transaction capture with and without central connectivity, persistence of the local record, end-of-day synchronization, central configuration, site reachability, register and peripheral behavior, shared fax submission, and recovery after network interruption. Field support also required tracing failures across application, network, endpoint, telephony, driver, signage, and service layers instead of assuming every issue belonged to the transaction client.
Result
Built, deployed, and supported across several operating locations.
The platform and supporting site technology operated across a corporate office, call center, and several thrift-store locations. Store staff could continue capturing transactions during a central-connectivity interruption and synchronize the recorded activity later.
What I learned
Make the offline boundary explicit and observable.
The architecture worked because local capture and central synchronization were separate responsibilities. A modern iteration would add transaction-level idempotency, explicit sync-state diagnostics, bounded retry queues, integrity checks, automated failure-path tests, and operational dashboards without weakening local continuity.