Building a Loyalty Network That Scales
Cosmo is not a marketplace and not an aggregator. It is infrastructure, and infrastructure is judged on whether it stays up, scales with demand and keeps data safe. Banks, fintechs and card issuers rely on Cosmo to issue and settle rewards across several loyalty programs, so the architecture is built for production from the first line. This article walks through how the network runs on AWS: the compute model, how it scales, how releases ship without downtime, how the network is segmented, and how access is controlled.
Cloud-Native by Design
Cosmo runs on a fully containerized microservices architecture powered by AWS ECS on Fargate. There are no servers to manage, no fixed compute ceilings, and no manual provisioning. Each service — whether handling point issuance, settlement logic, partner routing, or rule validation — runs independently inside its own container.
This creates immediate advantages:
| Capability | Outcome |
|---|---|
| Stateless services | Horizontal scale without redesign |
| Isolation | Failures do not cascade |
| Independent deployments | Faster iteration without risk |
Elastic Scalability
Demand in loyalty infrastructure is not linear. A single partner campaign, card launch, or redemption surge can create traffic spikes. Cosmo handles this through ECS Fargate Auto Scaling, where services scale automatically based on CPU utilization, memory usage, queue depth, and custom business metrics.
This means:
- No pre-provisioning required
- No overpaying for idle compute
- No performance degradation during demand bursts
Capacity grows when needed and contracts when not. The network expands with usage — not forecasts.
Zero-Downtime Releases
Reliability requires safe change. Cosmo uses Blue-Green Deployments via ECS, CodeDeploy, and Application Load Balancers (ALBs). New versions are deployed alongside existing ones:
| Environment | Role |
|---|---|
| Blue | Live production |
| Green | New release |
Traffic is gradually shifted from Blue to Green only after health checks pass, integration tests validate, and latency stays within threshold. Rollback is instant — no downtime and no disruption to live transactions.
Traffic Routing
All inbound service traffic flows through Application Load Balancers (ALBs), which provide Layer 7 routing, health-aware traffic distribution, and automatic failover. Requests are routed only to healthy containers, approved services, and valid environments. Unhealthy instances are removed automatically.
Network Isolation
Security starts with architecture. Cosmo operates across segmented VPC environments — Production, Sandbox, and Development — each fully isolated from one another. Within them:
- Services run in private subnets
- No direct public exposure
- Internet access is controlled via NAT
External access happens only through approved entry points.
Security Groups: Default Deny
Access is not assumed — it is explicitly granted. Every service sits behind tightly scoped Security Groups:
| Rule Principle | Implementation |
|---|---|
| Default deny | Nothing talks unless allowed |
| Least privilege | Only required ports opened |
| Service-to-service control | Traffic allowed by identity, not IP |
| No lateral movement | Internal isolation enforced |
For example, issuance services cannot speak to settlement databases, partner routing layers cannot access secrets stores, and external APIs cannot reach internal compute. Every path between services is explicit and reviewed.
Locked Down Access
Cosmo enforces access boundaries at multiple layers:
- IAM-Based Service Identity: Services authenticate using roles — not static credentials. No embedded secrets and no shared keys.
- Secrets Manager Integration: Sensitive values are encrypted at rest, rotatable, and never exposed in code or environment configs.
- Private Endpoints: Internal AWS services (databases, queues, secrets) are accessed through private network paths — not the public internet.
Defense in Depth
Security is layered. Compromise in one layer does not grant access to another:
| Layer | Mechanism |
|---|---|
| Network | VPC isolation |
| Access | IAM roles |
| Secrets | Encrypted storage |
| Compute | Container boundaries |
| Traffic | ALB health gating |
| Deployment | Blue-green validation |
Data Protection and Resilience
Compute isolation is only part of the picture. Data is encrypted at rest in every database, and personal data is encrypted again at field level with AES-256, so a database-level compromise does not expose member identifiers. The production database runs across multiple availability zones with point-in-time recovery for the previous 30 days. Audit logs are retained for twelve months, and administrative access requires multi-factor authentication. These controls are independently audited: Cosmo is SOC 2 Type II compliant and certified to ISO/IEC 27001, 27017, 27018 and 20000-1. The trust and security page lists the certifications and how to request the reports.
Why This Matters for a Loyalty Network
A bank integrating with Cosmo is routing live customer transactions through it, often at the moment a member is watching a progress bar in an app. A partner program is trusting the network with its members' identifiers and its receivables. Neither can tolerate an outage during a campaign spike or a release that corrupts a ledger. Stateless services, automatic scaling, blue-green releases, default-deny networking and encrypted data are the practical answers to those requirements. They are also what let a small team run infrastructure that financial institutions can put on their own risk registers with a straight face.
Built for Institutional Trust
Cosmo's infrastructure is designed for production at scale, not for demos. Every architecture decision follows one principle: financial institutions must be able to trust the network they build on, and that trust has to be earned in the design rather than promised in a slide.