Table of Contents

When you build software for kiosks, you’re not building another web app – you’re building a machine that must survive low memory, unreliable network, offline transactions, and real-time customer usage without ever crashing.

This is the story of how we diagnosed and fixed two deeply complex performance problems in a food-ordering kiosk system built with Angular 12, .NET, Node.js Development and Verifone – running on a Samsung Tizen OS device with just 4GB RAM.

And yes – the kiosk kept taking orders even without the internet.
That was both the feature… and the monster we had to tame.

The Kiosk – At a Glance

This wasn’t just a touchscreen menu.

It was a full standalone ordering machine:

• Customers browse menu → place order → pay
• Works online and offline
• Payments routed through Verifone terminal
• Syncs menu data & offline transactions regularly
• Prints receipts, pushes orders to POS & Kitchen Display

This means everything – UI, sync engine, printing, payments – shares limited CPU, memory, and a single communication channel to Verifone.

So when something goes wrong, everything breaks.

The Two Problems That Almost Killed Performance

1. Menu Sync: Thousands of Images = Memory Explosion

The kiosk regularly downloaded and updated menu content, including:

• 1,000 to 5,000+ images per outlet
• High resolution required for display
• Sync triggered frequently based on configuration

The original implementation subscribed to events for each downloaded image…

1000 images → 1000 active event
5000 images → 5000 events waiting in memory

The result?

• Memory consumption spiked
• UI began lagging
• Printer froze mid-operation
• Kiosk eventually required manual restart

Not ideal when customers are mid-order.

How We Fixed It

We changed the sync pipeline to:

• Download image
• Process
• Immediately destroy events

No stack buildup. No memory leak. Simple but game-changing.

• Final output rate: 2–3 images per second
• UI stayed smooth, printer remained responsive
• Memory consumption stabilized drastically

2. Offline Sync + Live Payments = Node Crash

The System Supported Offline Payments – Great.
But when the internet returned, the Kiosk synced them to the backend – Also great.

EXCEPT when sync & live payment happened simultaneously.

Here’s the trap:

• Browser cannot talk directly to Verifone (CORS + PCI restriction)
• So Angular → Node → Verifone socket is the only path
• Verifone allows one command at a time
• Node was stuck at v4 – no chance of upgrading
• No official SDK or NPM to optimize communication

So the moment:

Offline sync fetching old transactions AND Customer tries to make a live payment

• Both fight for same socket
• Node module crashes
• Kiosk freezes
• Printing stops
• No orders continue

A total service breakdown.

Root Cause + Permanent Fix

Instead of parallel execution, we serialized Verifone communication:

The key rule: Never let syncing and payment run at the same time.

And it worked.

• No more socket clashes
• No Node crashes
• Payments & sync both stable
• No kiosk downtime during rush hours

What This Taught Us

Engineering for kiosks is a different battlefield.

You don’t get infinite memory.
You don’t get the luxury of retries.
You don’t get to deploy patch updates easily.

Every solution must be efficient, resilient, and edge-case proof.

This project pushed us to dig beyond surface bugs and understand:

• Memory lifecycles
• Hardware limitations
• Offline queuing
• Device communication constraints
• Verifone single-socket behavior

The stability we achieved wasn’t from rewriting the system – but from understanding it deeply and reducing friction at the core.

Final Results