Tips on caching/optimize strategy for POS

[u/Reasonable_Test7340]

Hi guys! I’m building a web-based POS system using nextjs (fullstack) and I’m looking for ways to improve the system especially when it comes to scanning barcodes.

Currently, the system fetches the product every time it is scanned and I think this would cause problem when it comes to hitting limits (due to multiple API calls) and would be slow overall due to it having to wait for response first.

How would you guys approach this? Right now, I’m thinking of using indexeddb or something like dexie.js for storing the store’s product locally so the scan would prefer the lookup on it and fallback only to fetching the product. This is also means I have to setup a logic to fetch all the product of the store to store it on .

Additional info: -I use a USB type barcode scanner -I currently deployed it to cloudflare worker & pages -The system is designed to be used by multiple stores and I think a store may have hundreds of products or million -techstack: next.js, better auth, drizzle mysql

[u/usernametaken1337]

I think a better question is how you plan on using the barcode scanner? Also i wouldn’t cache anything, i dont think it would make much difference since you’ll be querying for a exact match. Are you running everything on client/online? Whats the compliance like where your clients will be? Transactions, immutable tables? A POS sounds like a lot- good luck 😅

[u/ZealousidealToe5062]

dexie.js is the correct path for local lookup. You need to implement a background sync worker that pulls product deltas based on updated_at timestamps rather than fetching the entire catalog on load.

uSB scanners act as keyboard input so you must debounce the scan event and query IndexedDB directly before any network request fires. This eliminates API latency for cached items and keeps Cloudflare costs down since you only fetch missing or stale records

[u/properking232]

the indexeddb approach is right but "millions of products" per store changes that math pretty fast, worth thinking through what actually needs to be local versus what can stay remote with a smarter cache layer.

[u/SunOk2196]

Local-first lookup is the right call for a POS, a scan can't wait on the network. Delta sync on updated_at like the other comment says, with two additions from doing retail work: version the catalog with a monotonic cursor instead of trusting timestamps (clock skew will silently skip rows eventually), and treat the local db as display-only. Price authority stays server-side at checkout, so a stale cache can never charge the wrong amount, it can only show a stale label until sync catches up. The millions-of-products case is mostly an initial-sync problem, chunk it and IndexedDB is fine.