Loyalty Platform — Multi-Partner System

The platform is the largest multi-partner loyalty program in the Czech Republic. Unlike company-specific loyalty programs where you earn points at a single retailer, the platform connects over 15,000 partner locations into one ecosystem — from major retail chains through petrol stations to local restaurants and e-shops. More than 2 million members earn points on everyday purchases and redeem them for rewards, discounts, or experiences.

Our task was to completely rebuild the platform’s technology stack — replace an ageing PHP monolith with a modern system capable of processing tens of millions of transactions per month, integrate 25,000+ POS terminals, and provide partners with campaign management tools and analytics.

Challenge¶

Legacy PHP Monolith¶

The original platform was a classic PHP monolith built over ten years ago. The system served its purpose but gradually ran into serious limitations:

• Performance — processing points transactions during peak hours caused visible slowdowns across the entire system. Point balances were sometimes updated with a minute-long delay
• Technical debt — years of incremental development created a complex, hard-to-maintain codebase. Adding a new feature took weeks because it required understanding and modifying interdependent sections of code
• Scalability — vertical scaling hit its limits and horizontal scaling of the monolith was practically impossible
• Integrations — every partner required a custom integration. There was no standardized API, meaning onboarding a new partner took 4–6 weeks

25,000+ POS Terminals¶

A loyalty program lives and dies by its integration with POS (Point of Sale) terminals. When a customer pays at the checkout, the POS terminal must in real time:

1. Identify the member (by card, phone number, or app)
2. Verify membership and retrieve the points balance
3. Calculate points for the purchase according to the partner’s current rules
4. Credit the points to the account
5. Optionally apply a points-based discount

The entire process must complete within 2 seconds — the customer is standing at the checkout waiting. With 25,000+ terminals, this means thousands of simultaneous requests during peak hours. And POS terminals are a heterogeneous environment — dozens of different manufacturers, firmware versions, and communication protocols.

Complex Campaign System¶

Platform partners don’t just want a simple “1 point per CZK 10.” They require sophisticated campaigns:

• Time-limited promotions — “double points this weekend”
• Segmented offers — “5× points for members who haven’t made a purchase in 30+ days”
• Cross-partner campaigns — “shop at both partner A and B and receive a bonus”
• Gamification — “complete 5 purchases in a month and earn 500 bonus points”
• Tier system — multiple membership levels with progressive benefits

Campaign rules combine, overlap, and interact with one another. The engine must evaluate dozens of rules for each transaction in real time and determine the correct number of points — without errors and with full auditability.

Data Migration¶

Migration from the PHP monolith to the new platform involved moving:

• 2M+ user accounts with complete history
• 150M+ historical transactions
• 15,000+ partner profiles with configurations
• Campaign rules and templates
• Integrations with external systems (payment gateways, email marketing, SMS gateway)

The migration had to be carried out with zero downtime — the program runs continuously and any outage would mean non-functional POS terminals at thousands of merchants.

Solution¶

Modular Monolith with DDD¶

After a thorough analysis of requirements, we chose a modular monolith architecture over microservices. The reasons:

• Lower operational overhead — the platform team is mid-sized and operating dozens of microservices would require a disproportionate investment in infrastructure and DevOps
• Transactional consistency — points operations require strong consistency. In a monolith, database transactions can be used without distributed transactions
• Easier refactoring — modules communicate via in-process events and clearly defined interfaces, but share a deployment unit
• Evolution — a modular monolith can be split into microservices in the future by extracting individual modules

The architecture applies Domain-Driven Design (DDD) principles:

• Member context — member management, registration, profiles, tier system
• Transaction context — points transaction processing, balances, history
• Campaign context — campaign engine, rules, evaluation
• Partner context — partner management, locations, integrations
• Reward context — reward catalogue, reservations, fulfillment
• Analytics context — reporting, dashboards, data export

Each bounded context has its own domain model, repository layer, and API. Communication between contexts happens via domain events — asynchronously where possible, synchronously where immediate consistency is required.

Campaign Engine¶

At the heart of the system is the campaign engine — a flexible rule engine for evaluating points rules:

Campaign engine architecture:

1. Rule definition layer — a DSL (Domain Specific Language) for defining campaign rules. Partners define rules via a visual builder in the portal; the system compiles them into an optimized internal representation
2. Evaluation pipeline — upon receiving a transaction, the engine loads relevant rules (pre-filtered by partner and time range), evaluates conditions, and calculates points
3. Conflict resolution — when multiple rules apply to a transaction, the resolver determines priority (highest cashback, first match, cumulative — configurable per partner)
4. Caching layer — active rules are cached in Redis with invalidation on change, eliminating repeated database queries

The campaign engine processes an average of 400 transactions per second with a median latency of 15ms for a complete evaluation.

Real-Time Points Processing¶

Points transaction processing is implemented as a pipeline:

1. Ingestion — receiving a transaction from the POS terminal via REST API
2. Validation — membership verification, data format check, deduplication (idempotence key)
3. Enrichment — augmentation with partner metadata, purchase categorization
4. Campaign evaluation — rule evaluation by the campaign engine
5. Points credit — atomic write of points to the member’s account (PostgreSQL transaction)
6. Notification — asynchronous push notification dispatch, balance update in the app
7. Analytics event — publishing the event to the analytics pipeline

The entire pipeline runs synchronously up to step 5 (so the POS terminal receives a response within 2 seconds); steps 6 and 7 run asynchronously via the Celery task queue.

API Gateway for Partners¶

A standardized API dramatically simplified partner integration:

• REST API with OpenAPI 3.0 specification and interactive documentation
• Webhook system — notifications about events (new member, tier reached, campaign expiring)
• SDK for popular POS platforms (Storyous, Dotykačka, K2)
• Sandbox environment — a fully functional testing environment for integration
• Rate limiting and throttling — system protection against overload with a fair-use policy
• Versioning — API versioning with a 12-month deprecation policy

Onboarding a new partner was shortened from 4–6 weeks to 3–5 days — most partners can complete the integration self-service with the help of documentation and the SDK.

Member App and Portal¶

• Mobile app (iOS + Android) — digital card, points balance, history, nearby offers, rewards catalogue
• Web portal — alternative for members who prefer desktop
• Partner portal — campaign management, locations, employees, analytics, and reporting
• Admin portal — internal tool for the platform team — member support, system configuration, monitoring

Architecture¶

Infrastructure¶

The system runs on AWS with the following architecture:

• ECS Fargate — containerized application without the need to manage servers
• RDS PostgreSQL — managed database with Multi-AZ deployment for high availability
• ElastiCache Redis — cache layer for session data, campaign rules, and rate limiting
• Elasticsearch — full-text search in the rewards catalogue, partners, and locations + analytics
• S3 + CloudFront — static assets, partner logos, documents
• SQS + Celery — asynchronous task processing (notifications, reporting, batch operations)

The entire infrastructure is defined as code in Terraform with a modular structure. Deployment runs via GitHub Actions with automated tests and canary releases.

Monitoring and Alerting¶

• CloudWatch + custom dashboards — system metrics and business KPIs
• Sentry — error tracking with automatic classification and assignment
• PagerDuty — alerting with escalation policies for the on-call team
• Synthetic monitoring — simulated POS transactions every minute to verify end-to-end functionality

Data Migration¶

Migration from the legacy PHP system proceeded in three phases:

Phase 1: Shadow mode (4 weeks) — the new system runs in parallel, receiving copies of transactions and comparing results with the legacy system. Any discrepancy is logged and analyzed.

Phase 2: Dual write (2 weeks) — transactions are written to both systems. The new system is the “source of truth” for new transactions; legacy serves as a fallback.

Phase 3: Cutover (1 day) — POS terminals are switched to the new API endpoint. The legacy system is switched to read-only mode for historical data.

The entire migration was completed without a single minute of downtime and without the loss of a single transaction.

Results¶

Business Metrics¶

After deploying the new platform, significant improvements were recorded across key business metrics:

• 60% increase in member engagement — thanks to personalized offers, push notifications, and gamification. Active members (at least 1 transaction per month) grew from 35% to 56%
• 3× faster partner onboarding — a standardized API and SDK reduced integration time from 4–6 weeks to 3–5 days
• Single API — instead of dozens of custom integrations, one standardized endpoint for all partners
• 15,000+ partners — growth from 8,000 to the current state thanks to easier onboarding
• NPS score 68 — a significant improvement over the legacy platform’s score of 41

Technical Metrics¶

• 10M+ transactions per month — processed without performance degradation
• < 200ms p99 latency on POS API (target was 2 seconds)
• 99.95% uptime — including peak season periods (Christmas, Black Friday)
• Zero data loss during migration of 150M+ historical transactions
• 75% reduction in operating costs — transition from dedicated servers to AWS managed services

Strategic Impact¶

The new platform enabled the program to:

• Expand into new verticals — hospitality, fitness, health & beauty
• Launch new products — platform Pay (pay with points), platform Experiences (experiential rewards)
• Data monetization — anonymized transactional insights for partners
• White-label solution — platform as a foundation for loyalty programs of other brands

The project transformed the platform from a legacy loyalty program into a modern technology platform capable of competing on the European market.

Technology¶

The project is built on a Python/Django stack, which provides rapid development and a rich ecosystem. PostgreSQL serves as the primary database with robust transaction and JSON operation support. Redis ensures sub-millisecond cache for hot data. Elasticsearch powers full-text search and analytics. Celery with a Redis broker handles asynchronous tasks. The entire system runs in Docker containers on AWS ECS Fargate, with infrastructure managed via Terraform.