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:

• Food (food): Manages real-time food and beverage ordering pipelines, processing menus, merchant availability, and dispatch routing for culinary merchant partners.
• E-Commerce (ecommerce): Powering digital retail storefront transactions from localized retail merchants and e-commerce partners.
• Service (service): An abstract domain layer for handling on-demand professional labor. Its production implementation utilizes specialized database schemas like OrderClean to manage real-time cleaning service bookings.
• Custom Concierge (costum): A high-flexibility personal concierge procurement service allowing users to order custom, non-listed items. This is engineered utilizing an isolated data pipeline mapped across the OrderCostum and DetailOrderCostume models.
• Express (express): A point-to-point peer-to-peer instant courier and logistics fulfillment engine requiring sub-second dispatch calculations.
• Pre-Order (preorder): Handles high-latency food or retail orders requiring specialized merchant preparation periods before courier assignment, utilizing the OrderPreorder model state-machine.
• E-Money (emoney): A digital asset distribution hub facilitating seamless balance purchasing and top-ups for prominent e-wallets (e.g., ShopeePay and the affiliated AtozPay ecosystem) running via the ProductEmoney model ledger.
• Cash Out Point (cash_out_point): Governs financial settlement and ledger point deductions, allowing users to withdraw liquidity from their platform balances or accumulated promotional reward points.
• Mall (mall): A specialized geo-fenced shopping layer designed to route food and product procurement exclusively from anchor tenants located within verified partner shopping malls.

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:

• Monthly GMV (January): Processed an aggregate transaction volume of Rp 3,761,171,400 before promotional discounts, settling at a net volume of Rp 2,376,291,000 After Discounts.
• Single-Day Traffic Value (Jan 22): Successfully computed and cleared Rp 291,496,500 before discounts, settling Rp 181,864,750 After Discounts within a single day.

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.