ATOZGO

Atozgo is an enterprise-grade, hyper-local on-demand delivery and multi-service super-app engineered to handle real-time logistical coordination between consumers, merchants, and couriers. Designed around a highly resilient backend infrastructure, the platform orchestrates diverse service models—ranging from food delivery and personal concierge procurement to digital wallets and financial cashouts—while maintaining low latency and strong transactional consistency.

This case study details the technical architecture, business domain breakdown, external gateway abstractions, and production metrics that validated the platform's engineering design under heavy load.

1. Core Business Domain Architecture

To achieve clean separation of concerns and high modularity, the platform’s business logic is decoupled into 9 Primary Core Business Domains. At the data layer, these services are handled dynamically through polymorphic associations or specialized database models mapped via the type_order attribute in the core Order model:

2. High-Availability Third-Party Integration Layer

Operating an on-demand ecosystem requires secure, asynchronous, and fault-tolerant orchestration with external provider infrastructures. The backend isolates these third-party dependencies through specialized integration services categorized into 4 Core External Channels:

I. Financial Gateway (Finnet / Finpay)

Serves as the primary financial bridge supporting intensive banking operations. This engine handles secure user registrations, automated KYC (Know Your Customer) processing, real-time balance inquiries, account transaction mutations, electronic bill payments, top-ups, and an atomic reversal system to securely undo failed or timed-out transactions without ledger corruption.

II. Affiliated E-Wallet API (AtozPay API)

A highly optimized, deeply bound integration connecting to the partner e-wallet platform (AtozPay) to serve as the application's default cashless checkout framework, avoiding high card-network latencies and ensuring frictionless transaction settlements.

III. Resilient Message & OTP Routing (InfoBip API & Local SMS Gateway)

Engineered for reliable, low-latency delivery of highly sensitive security codes and multi-factor authentication. The communication microservice operates a deterministic fallback pattern: it initiates transaction payloads via the InfoBip API; if network degradation or a timeout is detected, it instantly executes an automated fallback loop to a Local SMS Gateway (smsatoz.com).

IV. Real-Time Event Notifications (Firebase Cloud Messaging - FCM)

To maintain real-time situational awareness across the three user endpoints (Consumers, Merchants, and Couriers), the platform integrates FCM. Event listeners on the order lifecycle state-machines trigger asynchronous push notifications immediately as order conditions transition (e.g., Order Accepted $\rightarrow$ Preparing $\rightarrow$ Out for Delivery).

3. Production Scaling Metrics & Business Validation

The performance of this technical architecture was fully validated under high-concurrency production environments. Data extracted from the business performance report in image demonstrates the platform's robust throughput capabilities and transactional scale:

Transaction Volume & Operational Throughput

The system demonstrates elite transactional scalability, handling a staggering 154,381 total hits/transactions within a single month (January). The structural resilience of the platform's state-machines is underscored by an outstanding 92.48% Order Completion Rate (142,779 Delivered Orders), showcasing high reliability across couriers and merchants under sustained monthly traffic.

Peak Single-Day Performance Snapshot (January 22)

During a single-day peak volume stress test on January 22, the system effortlessly processed 12,982 total transactions in a 24-hour window. Even under this intense traffic surge, the server architecture and notification engines maintained high efficiency, processing 11,320 successfully finished transactions (representing an 87.20% completion rate in peak concurrency).

Financial Value & Gross Merchandise Value (GMV)

The database ledgers efficiently and securely tracked large financial volumes, validating the accuracy of the integration layers:

Core Technical Key Takeaways

1. Polymorphic Order Structuring: Architecting the 9 business domains under unified order abstractions while deploying clean child data models (OrderCostum, OrderPreorder, OrderClean) preserved codebase modularity and limited table bloat.
2. Deterministic Fallback Design: Building automated fallback loops for mission-critical paths (InfoBip to Local SMS) decreased notification drop-off rates, protecting the user authentication experience.
3. Performant Payment Reversals: Integrating atomic transaction checks and strict reversal flows within the Finnet/Finpay gateways eliminated database race conditions during concurrent digital wallet top-ups and balance payouts.