TV SMS Architecture

Evolution

Agenda

  1. Project Overview
  2. v1.0
    1. Technical Architecture Evolution
    2. Report
    3. Findings
  3. v2.0
    1. Approach
    2. Architecture
    3. Learnings

Project Overview

Objective: Create a P2P platform application to execute mass SMS and MMS campaigns for fundraising and GOTV messages.

 

Goal: Send around 4 million messages daily

 

Initial Feature Set

 

  • User permissions and Roles
  • Campaign and Contact List Management
  • Phone numbers Management
  • Text Deployment and Delivery
  • Reporting and Error Handling

1

Proposed Architecture

Initial Architecture

2.1.1

Message Status Workflow

  • Created in CMS
  • Queued by Clicker
  • Sent/Failed to SMS delivery platform
  • Delivered/Failed by SMS delivery platform
  • Opted out by consumer

Decoupling Database

Architecture II

2.1.2

  • started refining code
  • remove external dependencies
  • security fixes
  • replace local database with RDS primary and replica databases

Multithreading

Architecture III

2.1.3

  • increase send capacity
  • use multiple PHP threads

Serverless

Architecture IV

2.1.4

  • use Lambda functions
  • use SQS queues
  • highly scalable
  • direct DB update

Serverless Scalable

Architecture V

2.1.5

  • 18 Production environments
  • sending an avg 2M/day
  • max 5.68M

2.2

Challenges

  • Testing required for large campaigns
  • Monitoring message in various stages
  • Deployment to AWS resources
  • Maintaining multiple servers and databases
  • Consolidating distributed databases into one
  • Delivery issues not necessarily code issues
  • Single SMS service provider
  • Report Generation

2.3.1

Learnings

  • Multiple environments not always the answer to increase throughput
  • Offload database intensive processes to asynchronous threads
  • Model BigData to not cause database operation conflicts
  • Track and update Business requirements as project evolves
  • Go Serverless for unknown and crazy-high scaling requirements
  • Keep database size in check by periodically archiving irrelevant data

2.3.2

2.0 Approach

3.1

  • Modernize Frontend Stack
  • Consolidate into a single instance
  • Full Serverless
  • Leverage existing advantages
  • Database Optimization
  • Replace crons with Lambda functions

2.0 Features

  • Feature parity with 1.0
  • Pre-processing contact lists to ensure valid numbers
  • Updates to toll-free vs. local number allocation
  • First come, first serve message send logic

3.1.1

2.0 Architecture in Build

3.2

Changes in 2.0 Build

 

  • Laravel for ORM integration with DynamoDB
  • Contextual SQS Queues
  • All heavy-lifting offloaded to Lambdas
  • Contact processing integrated with Twilio

2.0 Learnings - DynamoDB

  • No results... but did you check for unprocessed keys / last evaluated keys
  • Pagination isn't easy
  • Counting is hard
  • Read and write throttling
  • Know your access patterns

3.3.1

2.0 Learnings - Lambdas

  • Have a plan for managing lambdas across multiple environments
  • Aliases are great, but... (envs, log tracing)
  • Where did my message go
  • Log thoroughly and thoughtfully

3.3.2

2.0 Learnings - General

  • Don't hit the server if you can hit a Lambda directly
  • Don't spawn PHP CLI processes that can potentially create infinite loops
  • When dealing with scale like this, use real-world test cases
  • Get to end-to-end testing ASAP
  • Prioritize

Questions?

TV SMS Architecture Evolution

By knaini

Made with Slides.com

TV SMS Architecture Evolution

  • 150

More from knaini