Architecture
This page describes the high-level architecture of the Float Service and its relationship with other platform components.
Diagram source code: docs/modules/ROOT/images/diagrams/c4.py.
System Context
Float Service
The Float Service acts as the central hub for advance lifecycle management. It interacts with several internal and external systems to provide its functionality.
-
Internal Clients: The FloatMe Mobile App makes API calls via AWS API Gateway.
-
Data Storage: Uses a hybrid approach with RDS (PostgreSQL) for primary float records and DynamoDB for historical collection logs and metadata.
-
Core Integrations:
-
User Service: Retrieves user profiles and verified identity information.
-
Underwriting Service: Validates eligibility and manages approved float amounts/fees.
-
Payments Service: Executes the actual funds transfer (disbursement and collection).
-
Transaction Service: Monitors user bank account balances and income streams to trigger collections.
-
EventBridge: Emits events (e.g.,
user_float_created) for consumption by other downstream services.
Float Collections
The collection architecture is designed to handle both scheduled and event-driven repayment attempts.
-
Scheduled Collections: Triggered by EventBridge Rules, the Collections Scheduler identifies due floats and queues them in SQS for the Collections Worker to process.
-
Webhook Collections: The Webhook Worker listens to transaction streams (income detection). If an overdue float exists and criteria are met, it attempts an immediate collection.
-
Resiliency: All collection attempts are logged in DynamoDB to ensure compliance and prevent duplicate attempts.