Turning Point: My First AWS Cloud Architecture Role at Decision Desk HQ

[jaylong255]

---

title: "Turning Point: My First AWS Cloud Architecture Role at Decision Desk HQ"
description: "A memoir of my entry into cloud architecture at Decision Desk HQ, a startup revolutionizing election data reporting, where I learned AWS, Laravel, and hacked high-availability solutions under tight deadlines."
publishedDate: 2025-09-25
modifiedDate: 2025-09-25
lastReviewedDate: 2025-09-25
keywords:

• AWS cloud architecture
• Laravel PHP framework
• election data startup
• high availability caching
• vanilla PHP JavaScript
• infrastructure reverse engineering
• Decision Desk HQ
• real-time API
• startup engineering
• prompt-based frameworks
  topics:
• Career & Professional Development
• Development & Tools
  tags:
• aws
• laravel
• election-tech
• caching-strategies
• startup-memoir
  series: ""
  category: "Career"
  socialImage: "/images/turning-point-my-first-aws-cloud-architecture-role-at-decision-desk-hq-social.jpg"
  headerImage: "/images/turning-point-my-first-aws-cloud-architecture-role-at-decision-desk-hq-hero.jpg"
  isDraft: false
  isFeatured: true
  priority: 8
  canonicalUrl: "https://cyberworldbuilders.com/blog/turning-point-my-first-aws-cloud-architecture-role-at-decision-desk-hq"
  language: "en-US"

---

Turning Point: My First AWS Cloud Architecture Role at Decision Desk HQ

Overview

This post chronicles my first foray into AWS cloud architecture at Decision Desk HQ (DDHQ), a pioneering election data startup founded in 2012 by Brandon Finnigan. Initially a spreadsheet-based operation for real-time election results, DDHQ grew into a trusted provider partnering with outlets like NewsNation, BuzzFeed, and Vox. My role involved reverse-engineering infrastructure, learning Laravel, and implementing quick fixes for high-stakes election nights, marking a pivotal shift from vanilla PHP to structured frameworks and cloud practices.

Company Origins and Early Challenges

• Founding and Evolution: Started by John (initial spreadsheets) and Brandon Finnigan (truck dispatcher turned public face), DDHQ used a volunteer network on Discord to scrape state websites and gather on-site vote counts from precincts. Competitors like the Associated Press relied on similar tactics, but DDHQ aimed for faster, more accurate calls.
• Initial Tech Stack: Vanilla PHP, JavaScript, HTML, and raw SQL queries on a LAMP stack (Linux, Apache, MySQL, PHP). Data entry via a console app fed into a database, with AJAX for real-time widget updates on client sites (e.g., Fox, BuzzFeed).
• Growth Pains: As exposure increased, the system buckled under traffic, especially during high-profile events like Alabama's 2017 Senate runoff (electing Democrat Doug Jones in the red state).

My Entry and AWS Infrastructure

• Hiring and Setup: Recruited by John, I inherited a codebase from previous developers. Limited interaction with consultant Mohammad (an AWS-certified cloud architect followed on LinkedIn), who provided access and basic docs. Pre-Terraform era meant manual AWS console work.
• Reverse Engineering: Dissected Mohammad's high-availability setup: multiple subnets, availability zones, load balancers. Documented duplication instructions, a tedious process later simplified by IaC tools like Terraform.
• Key Accomplishment: Alabama Runoff: With days to prepare, scaled for massive traffic. Inefficient app (no caching, heavy DB joins) crashed under load from widget requests.

Hacky Caching Solution Under Pressure

• Problem Diagnosis: Thousands of concurrent requests hammered the database with inefficient SQL joins for percentages and forecasts.
• Quick Fix Phases:
  1. JSON File Caching: Script checked file modified dates (naming convention by election ID). If <1 minute old, read JSON file instead of querying DB—reducing reads/writes and compute load.
  2. Cron-Staggered Queries: Background script ran every minute, staggering queries to flatten load spikes.
  3. Static HTML Generation: For widget-heavy clients, pre-built HTML files served directly by Apache (bypassing PHP via config rules), eliminating runtime processing.
• Outcome: Handled millions of requests on election night without crashes, outperforming expectations. A gritty, first-principles engineering win: identify core needs (1-5 min updates), constraints (time, resources), and deliver.

Transition to Laravel and API Development

• Framework Adoption: Proposed Laravel with Vue.js for the growing API—my excuse to learn a popular framework, but it enabled built-in caching, authentication, and docs (e.g., Swagger).
• Midterms and Texas Challenges: Scaled through 2018 midterms, but Texas overwhelmed due to sales volume. Many "developer" clients used WordPress without real devs, requiring API tutorials and hand-holding.
• Missed Optimizations: Time spent on client support delayed deeper dives into Redis, Varnish, Nginx caching, or AWS ElastiCache. My Apache/HTML hack mimicked these but wasn't scalable long-term.

Reflections on Vanilla vs. Frameworks

• Vanilla PHP Value: In today's AI era, vanilla enables light, fast prototyping—leverage LLMs for syntax, focus on logic. PHP's flexibility suits MVPs but invites bad habits without discipline.
• Emerging Frameworks: Predict a shift to prompt-based "zero-code" frameworks: high-level descriptions, vague snippets, and AI generation. Nascent now, but evolving beyond traditional code dependencies.
• Handoff and Exit: After ~1-2 years (post-2016 Trump election, pre-2018 midterms), DDHQ was acquired by Øptimus Analytics (2019-2021 timeline, later Dynata). Rewrote in modern, strongly-typed languages for enterprise maintainability (linters, tests). Stood up the API for knowledge transfer to new team.

Career Turning Point

• Skills Gained: AWS basics, Laravel mastery, high-availability hacks, and communication with non-technical stakeholders (founders like Brandon, McCoy/Drew McCoy).
• Nostalgia: Thrilling chaos of election nights; miss the intensity. DDHQ's success (first to call Trump 2016, Biden 2020) validates the scrappy engineering.

Suggestions on How This Content Might Be Useful to Others

• For Junior Developers: Illustrates thriving under pressure with pragmatic hacks, emphasizing first-principles problem-solving over perfection in MVPs.
• For Cloud Architects: Shares reverse-engineering tips for legacy AWS setups and the value of documenting manual processes before IaC.
• For Startup Founders: Highlights balancing quick fixes with client education, and when to adopt frameworks for scalability.
• For PHP/Laravel Learners: Contrasts vanilla vs. framework trade-offs, with real-world caching examples adaptable to high-traffic apps.
• For Election Tech Enthusiasts: Provides insider view on data aggregation challenges, useful for building real-time reporting tools.

Additional Information Validating Perspective

As a veteran of startup-to-enterprise transitions, my DDHQ experience aligns with industry evolutions: AWS's rise in election tech (e.g., Cloudflare's DDoS protection for DDHQ [3]) and Laravel's popularity for APIs (per Stack Overflow surveys, top PHP framework since 2015). The JSON/HTML caching hack echoes early Redis/Varnish patterns, validated by AWS case studies on ElastiCache for real-time apps. DDHQ's trajectory—first to call key races (Trump 2016, Biden 2020 [0]) and partnerships (Nexstar, The Hill [0])—confirms the impact of scrappy scaling. Øptimus acquisition (co-founder Scott Tranter's data firm [12]) underscores rewriting MVPs for enterprise, a pattern in Fast Company's 2020 DDHQ profile [2]. Prompt-based frameworks reflect trends in AI tools like GitHub Copilot, positioning this as forward-thinking memoir.

Cleaned-Up Transcript

I'm going to talk about my first AWS job, my first cloud architecture role, and it was a turning point in my career. It was also where I learned Laravel, the PHP framework. It was Decision Desk HQ (DDHQ), another startup providing election data on election night. It started with spreadsheets. I was hired by a guy named John, who had patched together the initial solution from spreadsheets. Then others worked on it: another developer wrote vanilla PHP, vanilla JavaScript, no framework, just raw SQL queries. It was on AWS—I don't know if initially, but a guy named Mohammad, a cloud architect I follow on LinkedIn, set it up. He has real insights on AWS infrastructure. I barely contacted him; he was busy, provided access and some docs via email. I reverse-engineered his network and load balancer. He was an AWS-certified cloud architect and contractor, like what I did for years. Pre-Terraform, no infrastructure as code. I documented instructions to duplicate his architecture—a standard high-availability setup with subnets and availability zones. It had a few extras; I proposed read/write replicas for long-term engagement.

The biggest accomplishment was the Alabama runoff, electing the Democrat senator—a big deal in the reddest state. I live in Alabama; there are Democrat pockets. Politics aside, it drew huge turnout. They'd had issues in a smaller election, and now with exposure, they sold widgets to news sites for real-time data. The system crashed under simultaneous hits. The app was inefficient—no caching. I didn't know Varnish, Redis, or Nginx caching then; frameworks handle it. With a week to prepare, I built a simple solution to cut DB reads/writes and compute.

What we needed: HTML pages updating every 1-10 minutes (ideally 1; over 5 risked AP beating us). I wrote a script querying every district. Back up: DDHQ forecasted elections to call first and right. John used spreadsheets for precinct data; partnered with Brandon (California truck dispatcher) with a nationwide volunteer network on Discord. For each precinct: scrape state websites or on-site volunteers (vs. AP yelling for counts). Data entered via vanilla PHP/JS/HTML console app with AJAX. Widgets queried DB, ran calculations for percentages, district sizes, candidate counts—real-time updates. Brandon did podcasts; I talked most to McCoy (first name escapes me).

From spreadsheets, they hired a dev for LAMP stack (Linux, Apache, MySQL, PHP). Queries were inefficient—first-thought joins. With days and juggling projects, I stepped in phases. First: cache queries. Instead of joins killing the DB, check if run in past minute; if yes, grab cached. I jammed data into JSON files; read files, not DB. Used naming convention for elections—no extra code/DB checks. Script checked file modified date by election ID. If <1 minute old, read JSON. Same computation as query, but offloaded DB for a minute; queried once per election at runtime.

Later, to avoid stacking, ran Cron job staggering queries per minute—flattened curves. Optimized further: big clients used widgets, not API. Built HTML files with naming convention; Apache logic served static HTML (bypassed PHP/reverse proxy if recent). No PHP execution—pure HTML serve. Handled millions of requests that night. Coolest career moment; engineers make you insecure about quality, but it solved the problem fast.

Stuck around; impressed, we built an API. Proposed Laravel/Vue—excuse to learn, but right call for caching/auth/docs. Did well through midterms, but Texas killed us—too many sales. Many "devs" were WordPress users without real coders (wealthy blogs, no legit devs). Trained on REST APIs; I had Laravel app, auth, Swagger docs, test environments. Clients promised dev access, but it was hand-holding.

Should've optimized caching (Redis, AWS ElastiCache), scaled DB, weighed Varnish vs. Nginx. My hacks mimicked them: Apache as Varnish, JSON as Redis key-value (not in-memory). Fun time, but most code was standard for growth.

Vanilla PHP/JS: now, with AI, it's light/fast—leverage LLMs for syntax, focus logic. PHP allows breaking rules, suits MVPs but invites habits. Frameworks emerging: prompt-based, zero-code—elaborate prompts explain problems, high-level strokes/sketches; AI generates. Nascent, but serves framework purpose.

Queries wildly inefficient. Steps: cut joins via cache. Ran logic checking run time; if recent, use data. JSON blobs or DB timestamps. File reads over queries. For elections: check file by ID; if fresh, read. Cut DB load entirely for minute; one query/election. Cron staggered to avoid spikes. For widgets: pre-build HTML; Apache served static if fresh—no PHP.

They didn't offer API to big clients—focused widgets. Built Apache config for direct HTML serve. Over time, impressed; fun period. Learned AWS, Laravel; hacked out of problems. Miss those days. Company exists; get election emails. Handoff to Chris; acquired by Optimus. Wanted rewrite—no PHP. Stood up API for transfer; new team used modern framework.

PHP fine if well-written, but long-term: strongly-typed languages, community pride in quality. PHP after-the-fact on quality/performance; used for hacks. Optimus: MVP great, now enterprise—linters, tests, coverage. Can do with PHP, but...

Made solid ending, prattled on.