All projects
corporate

OSOSS (zFloos) — A Multi-Tenant SaaS That Got 30% Faster Without New Hardware

SaaS Platform · Multi-Tenant · Redis · SQL Indexing · Async POS Sync

Client
OSOSS (zFloos)
Industry
FinTech / SaaS
Location
Saudi Arabia
Year
2024
Preview the live site
Project media

See the work in context.

Move through the published screens and walkthroughs. Images open at full size; videos play with their own controls.

Desktop interface

30%

API performance improvement

measured over 30 days

eliminated

POS terminal hang time

async queue

fast

Dashboard load (P95)

Redis + indexing

1,000s

Tenants supported

shared infrastructure

Project brief
Client
OSOSS (zFloos)
Industry
FinTech / SaaS
Location
Saudi Arabia
Work included
Web Development

OSOSS's zFloos platform serves thousands of Saudi businesses on shared infrastructure. As the tenant count grew, API performance degraded. We delivered a 30% performance improvement through SQL indexing and Redis — no infrastructure changes, no downtime, and POS terminals that now never hang waiting for the cloud.

01 / Project Overview

The situation

zFloos is a cloud ERP and point-of-sale platform used by thousands of businesses across Saudi Arabia — restaurants, retailers, service businesses — each with their own data, products, transactions, and reports sharing the same underlying infrastructure. Multi-tenancy at this scale creates a specific performance problem: every query needs a tenant scope filter, and poorly indexed tenant-scoped queries become exponentially slower as the tenant count grows. When we joined the project, P95 API response times had crept above 2 seconds for dashboard queries — a number that was getting worse every month as the customer base expanded. We ran a comprehensive query audit across the most-accessed endpoints: dashboard summary, transaction history, product catalog, and inventory reports. The pattern was consistent — tenant_id filter columns weren't part of composite indexes, meaning even indexed queries degraded to partial scans at scale. The indexing work alone delivered a measured 30% API performance improvement over 30 days. Redis caching was layered on top of the read-heavy dashboard queries that don't require real-time accuracy — metrics that refresh on a 5-minute cycle, for example, don't need a fresh database query on every page load. Separately, the POS sync architecture was causing terminal-side delays. When a cashier completed a transaction, the terminal waited for cloud acknowledgment before showing the success screen. If the cloud was slow — and under load, it was — terminals hung. We moved POS sync to an async queue: the terminal confirms locally, the cloud sync happens in background, and the cashier sees a success screen instantly.

02 / The Challenge

What had to change

API response times were degrading month-over-month as the tenant count grew — a natural consequence of unindexed tenant-scoped queries becoming slower at scale. POS terminals were hanging during busy periods because transaction cloud sync was synchronous: terminal success was gated on cloud acknowledgment.

03 / Our Solution

What we changed

Full query audit across all major endpoints. Composite index strategy on tenant_id + query-specific columns — delivered 30% measured improvement. Redis cache layer on dashboard aggregates with TTL matched to refresh cadence. POS sync made fully async: terminal confirms locally, cloud sync queued and processed in background with guaranteed delivery.

04 / Deliverables & outcomes

What the client gained

  • 01 30% API speedup — pure optimization, no new hardware
  • 02 POS terminals never wait for cloud acknowledgment
  • 03 Redis dashboard cache with smart TTL per report type
  • 04 Tenant data isolation correct at the query level
Bring the next constraint

Have a project that needs a clearer way forward?

Discuss the project

1 / 2