A consumer lending platform with 2.5M+ users had a push notification service that collapsed under production load. Azati refactored the system from scratch, introducing async queues, timezone-aware batching, composite indexes, and a statistics cache layer, turning a broken tool into a full marketing channel without adding infrastructure the client didn't want.
push notifications processed per day after refactoring
users served on the rebuilt notification infrastructure
months of active development with zero production outages
Consumer lending platforms live and die by communication timing. A push notification sent at the right moment about the right loan event is a retention tool. One that doesn't arrive is a missed opportunity at best, a broken promise at worst.
The client is a consumer lending platform with 2.5M+ registered users. Their push notification service had been built in-house and it showed: no async processing, no batch splitting, no database indexes. The service was collapsing under production load, notifications weren't being delivered, and marketing campaigns were launching into silence. Azati was brought in to refactor the core, add the missing infrastructure, and build analytics and marketing features on top.
The original service processed every notification synchronously, with no queue, no batching, and no indexes to support the query patterns needed at scale. At 1M+ users it was already breaking. At 2.5M it would have been completely unusable:
The marketing team needed a proper analytics dashboard, but the client explicitly didn't want to introduce a columnar database like ClickHouse. The data volume made real-time queries on standard tables impractical:
The service couldn't be taken offline for a migration. Business logic had to be preserved exactly, and new features, tracking, statistics, promo codes, were being scoped and built at the same time as the core refactoring:
Sending 50K notifications in a single batch regardless of recipient timezone meant waking users up in the middle of the night and degrading open rates. Proper delivery required per-user timezone awareness baked into the send pipeline:
The client needed a backend engineer who could inherit a broken codebase, stabilize it, and extend it without disrupting what was already running. The scope grew as the core was stabilized, covering both infrastructure refactoring and new feature development:
Inheriting a broken production service and refactoring it without downtime is not a job for someone still learning the framework. The Azati engineer brought fluency in Laravel's queue system, job processing patterns, and database optimization at scale, which meant being productive on a codebase with real constraints from day one.
The client's refusal to add ClickHouse or another columnar database was a real constraint. Rather than pushing back, Azati designed an async pre-computation pattern on PostgreSQL with a statistics cache layer and job deduplication guard that delivered the analytics the marketing team needed without touching the infrastructure budget.
Refactoring the core and building new features simultaneously, on a live platform serving millions of users, requires discipline. The Azati engineer kept both tracks moving, with the core stabilized first and features built cleanly on top, delivering a system that was more reliable and more capable than what it replaced.
Push notifications in a lending context aren't generic marketing blasts. They map to specific loan lifecycle events: application, signing, payment due, overdue, extension offers. Understanding that lifecycle meant the tracking and targeting features were designed to match how the business actually works, not just what was technically convenient.
Whether you need to refactor a failing push system or build one from scratch for a high-scale audience, Azati has the backend depth to deliver it reliably.
Let's talk about your backendThe core of the refactor was replacing the synchronous send pipeline with a proper async architecture. Laravel Queue with Redis handles all notification jobs, splitting large sends into manageable batches across four time periods: hourly, 3-hour, daily, and weekly. Seven Laravel Commands and six Jobs were written to cover the full send lifecycle, from scheduling through delivery to status tracking.
Dead FCM tokens are a silent drain on delivery rates. Tokens accumulate as users uninstall apps or switch devices, and sending to invalid tokens counts against quotas and skews delivery metrics. The validation pipeline processes tokens in chunks asynchronously, identifies invalid tokens via FCM response codes, and removes them without blocking the main notification flow.
Notifications sent at 3am local time don't get opened. The batching engine resolves each user's timezone at send time and suppresses delivery between 22:00 and 07:00 local time. Users in different regions receive notifications within their active hours, which improves both open rates and the user experience for a platform that operates across multiple time zones.
Real-time analytics queries across millions of push log records on standard relational tables would destroy performance. The solution uses background jobs to pre-compute and cache statistics into a dedicated PostgreSQL statistics_cache table, with a job_dispatched flag preventing duplicate heavy jobs from running simultaneously. Three table types cover different reporting dimensions. The dashboard surfaces these pre-computed results instantly, with Excel export for overdue user lists.
The marketing team needed attribution beyond opens. Eight key loan lifecycle actions were tracked back to the originating push notification, including applications, signings, payments, repayments, extensions, offers, and reviews. Click tracking was implemented using short URLs, and a promo code system was added with a daily limit of 20 codes and SOAP integration with the client's 1C system for automatic discount application.
The operations and marketing teams receive automated daily reports via Telegram covering key push statistics: send volumes, delivery rates, conversion by action type, and token health. Reports are generated by scheduled jobs and dispatched via Telegram API, keeping the team informed without requiring anyone to log into a dashboard.
| Metric / area | Before engagement with Azati | After engagement with Azati |
|---|---|---|
| Service stability | Collapsed under production load | 0 outages after go-live on refactored system |
| Daily notification volume | Could not reliably deliver at scale | 50K+ notifications processed per day |
| User base served | ~1M at time of failure | 2.5M+ users on rebuilt infrastructure |
| FCM delivery rate | Degraded by dead token accumulation | Improved via automated token cleanup pipeline |
| Conversion tracking | No funnel visibility | 8 action types tracked from notification to completion |
| Statistics dashboard | Not functional at scale | Async pre-computed cache, instant dashboard queries |
| Marketing automation | Manual, unreliable | Promo codes, timezone batching, daily Telegram reports |
All external API endpoints are protected by API Key middleware with Laravel Sanctum handling authentication. Role-based access control is enforced via spatie/laravel-permission (RBAC) throughout the admin layer. Rollbar error monitoring and Laravel Telescope provide full audit trails of requests and job execution. All traffic runs over SSL/TLS with custom certificates. The system operates in compliance with applicable data protection requirements for financial platforms handling personal user data.
The engagement ran with one Azati backend engineer responsible for the full scope: refactoring the core, designing the database schema changes, building new features, and integrating with external systems. Working inside the client's Agile team meant participating in sprint planning and delivering continuously against a live production system.
The core engine and new features weren't developed sequentially. The refactoring was prioritized to stabilize the service first, with new capabilities built on top as the foundation solidified:
Before the engagement, the notification service was a liability. After it, the marketing team had a stable, analytics-equipped channel with conversion tracking, promo code mechanics, and automated reporting. A tool that was silent became one of the platform's active retention instruments.
The refactored service has not gone down under production load. It now processes 50K+ notifications per day across a user base that has grown to 2.5M+ since the refactoring, with no service failures.
For the first time, the marketing team could see which notifications drove loan applications, payments, and extensions. Eight tracked action types gave them a complete picture of notification-to-conversion performance, enabling data-driven campaign decisions.
The async pre-computation pattern on PostgreSQL delivered the statistics layer the team needed without adding ClickHouse or any other specialist database. The solution fits within existing infrastructure and performs well at the current data volumes.
The engagement built expertise inside Azati in high-load notification architecture, Laravel queue patterns at scale, FCM delivery optimization, and the consumer lending lifecycle that shapes how push campaigns are structured in this domain.
A few patterns from this engagement that go beyond the specific deliverables:
The statistics_cache pattern, where background jobs pre-compute heavy aggregations and store results with a deduplication guard, is a reusable solution for teams that need analytics performance but can't or won't add ClickHouse, BigQuery, or similar tooling. It works within standard relational infrastructure and scales reasonably well for mid-size data volumes.
Sending at the right local time isn't just user experience polish, it directly affects open rates and conversion. The pattern of resolving user timezone at send time and applying a suppression window is reusable for any platform with a geographically distributed user base and time-sensitive notifications.
The hardest part of this project wasn't writing new code. It was preserving existing business logic exactly while restructuring the system around it. That requires careful reading of the original codebase, disciplined testing, and a willingness to move slowly on the parts that matter most before accelerating on new features.
FCM delivery rates degrade silently as invalid tokens accumulate. The chunked async validation pipeline that identifies and removes dead tokens is the kind of maintenance work that gets skipped until it becomes a visible problem. Building it into the core infrastructure means the client's delivery metrics stay accurate as the user base grows.
The engagement ran with a single Azati backend engineer covering the full scope of refactoring and feature development over five months of active work on the service.
Production-grade algorithmic trading platform for a US prop firm: 5x faster backtesting, 2x PnL growth, and drawdown cut from 35% to 21% after ML-based risk management went live.
Azati stabilized and extended a broken Pact Broker, shipped enterprise features, and brought a stalled contract testing initiative to production.
AI orchestration layer that automates banking claims and loan amendment workflows across legacy systems while maintaining compliance and human oversight.
AI-managed support automation built on Zendesk and Confluence that reduced ticket load, improved CSAT, and scaled operations without new hires.
Automated problem management system using Jira with dashboards and real-time insights.
Modern banking system for SMEs with multi-channel payments and financial reporting.
Last updated