The product sitting on a store shelf didn't just appear there. Before a customer can buy it, whether in-store, online, via click-and-collect, or through curbside pickup, that item passed through dozens of mobile and digital workflows. 

At every step, a mobile or edge device was involved. And at every step, something could break. Small breaks aren’t very noticeable; It’s the chronic nature of these breakdowns that erode productivity and revenue, leaving behind glaring operational gaps that are rarely addressed. 

Retail operations have become entirely dependent on mobile workflows, yet most of these systems were architected with a dangerous assumption: 

• My devices will always be able to reach the internet
• My backend cloud will always be available
• My business-critical APIs will always be callable

When these assumptions fail (not if, but when) the consequences ripple outward. A scanner timeout in the fulfillment center becomes a delayed shipment. A hung inventory lookup becomes a lost sale when a customer can’t find a desired item on the floor. A stalled order sync becomes an angry customer waiting at curbside pickup.

The problem isn't that retailers don't invest in connectivity (because they definitely do.) It's that they've built mission-critical operations on top of an architectural pattern that treats network availability as a given rather than a variable. This is why you’ll so often see heavy investment in WiFi and 5G technologies to cover operational gaps that just can’t be solved by more and more hardware. 

Fulfillment Center Scanning: Where Small Delays Become Big Problems

Walk into any modern fulfillment center and you'll see workers carrying scanner devices. Handhelds, mobile computers, ring scanners on wearables. These devices are the nervous system of warehouse operations. Every receive, putaway, pick, and ship action flows through them.

The workflow seems straightforward: scan a barcode, the device makes an API call to the warehouse management system (WMS), the WMS updates inventory and returns the next task. Repeat thousands of times per shift.

But there’s a clear dependency chain that's only as strong as its weakest link. The device needs to maintain a WiFi connection. That connection needs to reach the local network. The network needs to route requests to the cloud-hosted WMS. The WMS API needs to respond. The response needs to travel back through the same chain. All of this needs to happen fast enough that the worker doesn't notice.

When any link in that chain degrades, the experience breaks down in ways that compound quickly. Consider just a couple common situations:

Network congestion during peak operations. Fulfillment centers can have hundreds of devices all hammering the same WiFi infrastructure simultaneously. Channel overlap, access point handoff failures (we see this a lot), and bandwidth saturation become inevitable during high-volume periods. The Cisco community forums are filled with warehouse IT teams troubleshooting these devices that "freeze" or have "roaming issues," symptoms that often trace back to too many devices competing for the same spectrum.

The scale of this problem is visible in IT support forums where warehouse teams troubleshoot these issues daily. In one representative thread on Cisco's community forums, a warehouse IT team describes scanner "RF guns" that are "occasionally freezing and having issues roaming" between access points. The solutions proposed are all infrastructure workarounds: adjusting data rates, disabling certain frequency bands, increasing transmission power, reconfiguring roaming settings. One commenter notes that after extensive network reconfiguration, they reduced drops "from 10-50 drops per day per gun to 0-2 drops per day total"—a dramatic improvement that still accepts multiple daily disruptions as the baseline. The thread is a perfect illustration of how the industry treats connectivity failures as a network problem to be managed rather than an architectural problem to be solved.

API latency and timeouts. Every scan that requires a round-trip to a cloud WMS is subject to network latency, API response time, and potential timeouts. When the system is under load (exactly when fulfillment speed matters most) response times creep up. Workers see spinning indicators. Operations slow. The timeout cascade begins: Service A waits for Service B, which waits for Service C, and suddenly a simple scan takes seconds instead of milliseconds. Might not seem like much, but consider how a few seconds across every worker over the course of a day might compound? Week? Month? 

Cloud service disruptions. Major cloud outages aren't theoretical risks. In October 2025, AWS experienced significant disruptions affecting services across the US-EAST-1 region. Microsoft Azure followed with its own outage days later, impacting services from Costco to Kroger. For fulfillment operations running on cloud-hosted WMS platforms, these outages didn't just cause inconvenience—they stopped operations entirely.

The common response to these problems is to invest in better infrastructure: more access points, faster internet, redundant connections. These investments help, but they don't address the fundamental architectural issue. No amount of infrastructure can guarantee 100% uptime for a system that requires constant connectivity to function.

Click-and-Collect and Curbside Pickup: The Moment of Truth

BOPIS (Buy Online, Pick Up In-Store) and curbside pickup have grown from convenience features to essential retail capabilities. Click-and-collect sales continue to grow at double-digit rates annually. For many retailers, these fulfillment methods now represent a significant portion of revenue.

The workflow seems simple from the customer's perspective: place an order, get a notification when it's ready, show up and collect it. Behind the scenes, the process depends on a chain of mobile workflows that must execute reliably:

1. The order arrives at the store and appears in the fulfillment queue
2. An associate receives the picking task on their mobile device
3. The associate locates each item, scanning to confirm picks
4. Items are staged in a designated area
5. The system notifies the customer that the order is ready
6. When the customer arrives, an associate retrieves and hands off the order

Each step requires connectivity. Each step can break.

The inventory availability problem. The order was placed based on inventory data that may already be stale. By the time the associate goes to pick the item, it might be gone—sold to another customer, miscounted in the first place, or simply not where the system says it should be. When this happens, the associate has to substitute, cancel items, or contact the customer—all of which require additional system interactions that may also fail.

The notification problem. Customer notifications depend on successful API calls from the store system to messaging services. If the store's network is congested or the notification service is slow, customers may not receive timely updates. They arrive expecting a ready order and find associates still picking—or worse, no record of their arrival.

The handoff problem. Curbside pickup adds another layer of complexity. The customer needs to check in when they arrive. The system needs to alert the right associate. The associate needs to locate the order, confirm it, and complete the transaction—often including payment processing. All of this happens in a parking lot where network coverage may be inconsistent, with a customer waiting in their car expecting speed and accuracy.

Industry surveys consistently identify common pain points: orders not ready when promised, poorly marked pickup locations, and long wait times. Nearly half of retailers report challenges with having orders ready quickly enough for in-store pickup. These aren't just operational failures—they're broken promises that erode customer loyalty.

What if the pickup workflow could function independently of cloud connectivity? What if order data, customer information, and inventory locations were available on-device? What if nearby devices could share information peer-to-peer, so an associate's tablet could communicate with a curbside kiosk without routing through a central server? The customer checks in, the nearest device receives the notification, the associate retrieves the order—all without depending on a round-trip to the cloud.

Why Better Infrastructure Isn't the Answer

The instinct when facing these problems is to invest in better connectivity. Faster WiFi. Redundant internet connections. Local servers. Private 5G networks. More access points. Better roaming configurations.

These investments aren't wrong, but they are only band-aid solutions. They attempt to solve a distributed systems problem with infrastructure, when the real issue is architectural.

Consider the failure modes:

WiFi congestion is inherent to high-density environments. A store with 50 mobile devices and 200 customer smartphones is fundamentally constrained by available spectrum. No amount of access point optimization eliminates contention during peak hours.

Cloud services will have outages. AWS and Azure together power a significant portion of retail backend systems. Both experienced major outages in late 2025. Multi-cloud redundancy helps, but adds complexity and cost. You can't outspend this problem.

API latency is physics. Round-trip time to a cloud datacenter has a floor determined by distance and network topology. For time-sensitive operations like scanning, even 100-200ms of latency creates noticeable friction. Under load, latency increases.

Network partitions are inevitable. Large retail facilities have dead zones. Delivery vehicles pass through areas without coverage. Store back-of-house areas often have poor signal. Any architecture that stops working in these conditions is fragile by design.

The retailers who avoid these problems aren't necessarily the ones with the best infrastructure. They're the ones who've stopped assuming perfect connectivity and architected around its absence.

Rethinking the Default Architecture

The pattern that connects all these failure modes is architectural: systems designed with connectivity as a requirement rather than an enhancement. Reversing this assumption leads to a different approach. Edge systems today need to be designed with 3 key things in mind.

Edge Data Capture. Mobile devices capture operational data—scans, counts, transactions—locally first. The device's local database is the immediate source of truth, not a cache or fallback. Work continues regardless of network state. When connectivity is available, data syncs; when it's not, work doesn't stop.

Edge Data Reconciliation. When multiple devices capture related data—two associates counting the same inventory area, a customer and an associate both modifying an order—conflicts will occur. Every device must converge to a consistent state without manual intervention that only slows things down.

Edge Data Distribution. Devices don't have to communicate through a central server. Peer-to-peer synchronization allows nearby devices to share data directly. An associate's handheld can receive an order update from a staging tablet. A delivery driver's phone can sync with a store's system when pulling up for a pickup. Information flows through whatever path is available.

This isn't theoretical architecture. Retailers implementing these patterns see measurable improvements: warehouse workers who scan and process inventory regardless of network state, store associates who operate during WiFi congestion, delivery drivers who continue tracking in dead zones.

The data eventually reaches backend systems—for analytics, for AI, for business intelligence. But operational continuity doesn't depend on that connection being present at every moment.

The Design Question

For every mobile workflow in your retail operations, ask: does this need to be synchronous with the cloud, or are we just defaulting to that pattern?

Fraud prevention requires real-time validation. Dynamic pricing needs centralized coordination. Payment authorization has regulatory requirements around connectivity.

But inventory counts? Package scans? Order picking? Customer check-ins? These operations don't need to block on network calls. They need to work in the worker's hands, regardless of what's happening with the WiFi, the API, or the cloud region.

The retailers who maintain operational continuity aren't the ones with the best network infrastructure. They're the ones who've stopped requiring it to be perfect—and architected for the reality that it won't be.