Paytm Insider offline-first POS

Senior Android Engineer20242+ years5 people2 min read

Built Android systems for live-event pressure: offline-first POS reliability, 36% smaller consumer app size, and a 4-second Events startup improvement.

Overview

At Paytm Insider, I worked on Android products that had to perform in the field, not just in ideal network conditions. The work combined offline-first POS architecture with consumer-app performance and observability improvements.

Problem

Event teams needed a POS app that could keep selling through weak connectivity, crowded venues, and fast queues. At the same time, the consumer app needed to become lighter and faster without slowing product delivery.

Constraints

  • Live-event usage arrives in spikes, often in venues where connectivity is unreliable.
  • Offline behavior still had to reconcile cleanly with near-real-time operational data.
  • POS mistakes could directly affect queues, entry, and event operations.
  • Consumer app optimization had to land without destabilizing active product surfaces.

Approach

I helped architect the POS app around local-first behavior, explicit caching rules, and synchronization tuned for event operations. In parallel, I worked on modular optimization, startup improvements, and production instrumentation with analytics, feature flags, and error logging.

Key decisions

Design the POS app as offline first

Reasoning

At a live event, network assumptions fail quickly. Local-first behavior kept the point-of-sale experience useful even when the environment was unpredictable.

Alternatives considered
  • Assume continuous connectivity and fall back only during errors
  • Limit app functionality when the network was unstable

Treat synchronization as a product concern, not just a data concern

Reasoning

Synchronization affected real operational decisions, so cache rules had to reflect how event teams worked on the ground.

Alternatives considered
  • Use a naive sync model with limited reconciliation logic

Invest in modular optimization for the consumer app

Reasoning

App size and startup time were visible to users, while modular improvements also made future changes cheaper.

Alternatives considered
  • Focus only on one-off performance patches

Tech stack

  • Kotlin
  • Android
  • Offline-first architecture
  • Caching
  • Synchronization
  • Feature flags
  • Analytics
  • Error logging

Result and impact

  • 5K to 50K footfall supported
    Event scale
  • 36% reduction
    Consumer app size
  • 4 seconds faster
    Events module cold start

The Android stack became more resilient for operations-heavy use cases, while the consumer app became lighter, faster, and easier to observe in production.

Learnings

  • Offline-first architecture is as much about operational empathy as storage strategy.
  • Performance work compounds when app size, startup time, and observability are improved together.
  • Event tech has very different failure modes from a typical always-online consumer app.

This work was grounded in real-world pressure: queues moving, networks shifting, and event teams needing the product to stay calm.

All projects