Skip to content

AWS Community Day App Ecosystem

Jump to bottom
Sebastian Marines edited this page Mar 16, 2025 · 1 revision

The Story

The Challenge: At the last AWS Community Day Mexico, volunteers were writing attendee badges by hand with markers. The agenda changed throughout the day, but updates weren't communicated effectively. Networking relied on business cards, and sponsors tracked leads using inconsistent methods. Session attendance wasn't tracked at all.

The Solution: We're building an integrated app ecosystem that automates badge creation, provides real-time agenda updates, enables digital networking, streamlines sponsor lead capture, and tracks session attendance—all while collecting valuable data for organizers.

The Vision: Create an open-source platform that any AWS Community Day can deploy globally.

System Overview

graph TD
    A[Eventbrite] -->|Webhook| B[Backend API]
    B -->|Message| C[SQS Queue]
    C -->|Notification| D[Badge Printer]
    B <-->|Data| E[DynamoDB]
    F[Central App Router] -->|Redirect| G[Agenda App]
    F -->|Redirect| H[Networking App]
    F -->|Redirect| I[Sponsor App]
    F -->|Redirect| J[Volunteer App]
    G <-->|GraphQL| B
    H <-->|GraphQL| B
    I <-->|GraphQL| B
    J <-->|GraphQL| B
    K[Attendee QR Code] -->|Scan| H
    K -->|Scan| I
    K -->|Scan| J
Loading

The Attendee's Journey

Meet Ana, a developer attending AWS Community Day Mexico:

  1. Registration: Ana registers on Eventbrite weeks before the event.

  2. Check-in: Upon arrival, a volunteer scans Ana's Eventbrite QR code.

    sequenceDiagram
    participant A as Ana
    participant V as Volunteer
    participant E as Eventbrite
    participant B as Our Backend
    participant P as Badge Printer
    
    A->>V: Shows Eventbrite ticket
    V->>E: Scans ticket in Eventbrite app
    E->>B: Webhook sends attendee data
    B->>B: Creates uninitialized profile
    B->>P: Sends badge printing request via SQS
    P->>V: Prints badge with unique QR code
    V->>A: Gives printed badge
    Loading

  3. Profile Setup: Ana scans her badge QR code with her phone, verifies her email, and creates her profile with a PIN.

  4. Agenda Planning: Ana browses the agenda app, bookmarks interesting sessions, and receives real-time updates when sessions change.

  5. Networking: When Ana meets Pat, another attendee, they exchange profiles by:

    • Pat enters their PIN
    • Ana scans Pat's badge QR code
    • Ana sees Pat's profile and can save contact info
    • The system logs this interaction for the networking contest

  6. Sponsor Interactions: Ana visits the AWS booth where:

    • The sponsor scans Ana's badge QR
    • The sponsor sees Ana's profile and takes notes
    • The system registers Ana's booth visit for the "visit all sponsors" raffle

  7. Session Attendance: Ana attends a session where:

    • A volunteer at the door scans her badge QR
    • The system records her attendance

Core Applications

1. Central Router Web App

Detects user type and directs to the appropriate application:

graph TD
    A[User Visits URL] --> B{Determine User Type}
    B -->|Attendee| C[Networking App]
    B -->|Sponsor| D[Sponsor App]
    B -->|Volunteer| E[Volunteer App]
    B -->|Organizer| F[Admin Controls]
Loading

2. Agenda App

Problem: Schedule changes happen, but communicating updates is difficult. Solution: Real-time agenda management with instant updates to all attendees.

Key Features:

  • Session browsing with filters
  • Session bookmarking
  • Real-time updates
  • Organizer editing interface

Technical Flow:

graph TD
    A[Organizer] -->|Updates schedule| B[GraphQL API]
    B -->|Stores changes| C[DynamoDB]
    D[Attendee] -->|Requests schedule| B
    B -->|Returns data| D
Loading

3. Networking App

Problem: Business cards get lost, and intentional networking is hard to track. Solution: Digital profile exchange with privacy controls and gamification.

Key Features:

  • Profile creation with social links and Builder ID integration
  • QR scanning with PIN protection
  • Connection tracking for contest
  • Anti-fraud measures using fingerprint.js

Technical Flow:

sequenceDiagram
    participant A as Attendee A
    participant B as Attendee B
    participant API as Backend API
    participant DB as DynamoDB
    
    B->>B: Enters PIN
    A->>A: Scans B's QR code
    A->>API: Sends QR data + PIN
    API->>DB: Validates PIN
    DB->>API: Returns profile if valid
    API->>A: Returns B's profile
    API->>DB: Logs connection
Loading

4. Sponsor App

Problem: Lead capture is inconsistent and often requires manual data entry. Solution: Streamlined profile access with note-taking and visit tracking.

Key Features:

  • Unique login for sponsors
  • Attendee QR scanning
  • Profile viewing
  • Note-taking with persistence
  • Visit logging for "visit all sponsors" raffle

5. Volunteer App

Problem: No way to track session attendance or manage room capacity. Solution: Simple scanning interface for session check-in.

Key Features:

  • Session selection interface
  • QR scanning for validation
  • Attendance tracking
  • Simple analytics

Technical Architecture

We're building a serverless application using:

  • AWS CDK for infrastructure as code
  • AppSync/GraphQL for the API layer
  • DynamoDB for data storage
  • Lambda for serverless functions
  • SQS for queue management
  • S3 for static hosting
  • Cognito for authentication
graph TD
    A[Frontend Applications] -->|GraphQL| B[AppSync]
    B <-->|Resolvers| C[Lambda Functions]
    C <-->|CRUD| D[DynamoDB]
    E[Eventbrite] -->|Webhook| F[API Gateway]
    F -->|Event| G[Lambda Function]
    G -->|Message| H[SQS Queue]
    H -->|Notification| I[Badge Printer Script]
    J[Cognito] -->|Auth| A
Loading

Data Model: DynamoDB Single-Table Design

We're using a DynamoDB single-table design to optimize for query patterns and minimize costs. All entity types are stored in one table with carefully designed keys.

Primary Table Structure

Table: AWSCommunityDayTable

Key Structure:
- PK (Partition Key): Entity type + ID (e.g., "ATTENDEE#12345")
- SK (Sort Key): Metadata or relationship info (e.g., "PROFILE" or "SESSION#678")

Entity Types and Access Patterns

graph TD
    subgraph "Single DynamoDB Table"
        A[PK: ATTENDEE#id<br>SK: PROFILE<br>Name, Company, Email, etc.]
        B[PK: ATTENDEE#id<br>SK: CONNECTION#timestamp#otherAttendeeId<br>Connection metadata]
        C[PK: ATTENDEE#id<br>SK: VISIT#sponsorId#timestamp<br>Visit notes]
        D[PK: SESSION#id<br>SK: METADATA<br>Title, Description, Time, etc.]
        E[PK: SESSION#id<br>SK: ATTENDEE#attendeeId<br>Attendance timestamp]
        F[PK: SPONSOR#id<br>SK: METADATA<br>Name, Description, Tier]
    end

    subgraph "GSI1: By Type"
        G[PK: entity_type<br>SK: sortable_attribute]
    end
    
    subgraph "GSI2: Inverted Index"
        H[PK: SK from base table<br>SK: PK from base table]
    end
Loading

Key Access Patterns

  1. Get attendee profile

    • PK = ATTENDEE#id, SK = PROFILE

  2. List all attendee connections

    • PK = ATTENDEE#id, SK begins_with CONNECTION#

  3. Get all visitors to a sponsor

    • Query GSI1: PK = SPONSOR#id, SK begins_with ATTENDEE#

  4. Get session attendance

    • PK = SESSION#id, SK begins_with ATTENDEE#

  5. Get all sessions an attendee visited

    • Query GSI2: PK = ATTENDEE#id, SK begins_with SESSION#

  6. List all sessions (for agenda)

    • Query GSI1: PK = entity_type (SESSION), SK = sort by startTime

Example Items

// Attendee Profile
{
  "PK": "ATTENDEE#A12345",
  "SK": "PROFILE",
  "name": "Ana Garcia",
  "company": "AWS",
  "email": "ana@example.com",
  "phone": "+5215512345678",
  "pin": "1234", // Stored securely
  "profileInitialized": true,
  "builderIdUsername": "anagarcia",
  "socialMedia": {
    "twitter": "@anagarcia",
    "linkedin": "linkedin.com/in/anagarcia"
  },
  "entity_type": "ATTENDEE"
}

// Session Data
{
  "PK": "SESSION#S789",
  "SK": "METADATA",
  "title": "Serverless Architecture Patterns",
  "description": "Learn about common serverless patterns...",
  "speaker": "Carlos Rodriguez",
  "track": "Architecture",
  "startTime": "2023-09-15T10:00:00Z",
  "endTime": "2023-09-15T11:00:00Z",
  "location": "Room A",
  "entity_type": "SESSION"
}

// Attendance Record
{
  "PK": "SESSION#S789",
  "SK": "ATTENDEE#A12345",
  "timestamp": "2023-09-15T10:05:23Z",
  "entity_type": "SESSION_ATTENDANCE"
}

// Connection Between Attendees
{
  "PK": "ATTENDEE#A12345",
  "SK": "CONNECTION#20230915T104523Z#A67890",
  "connectedAttendeeId": "A67890",
  "timestamp": "2023-09-15T10:45:23Z",
  "entity_type": "CONNECTION"
}

// Sponsor Visit
{
  "PK": "ATTENDEE#A12345",
  "SK": "VISIT#SP456#20230915T123045Z",
  "sponsorId": "SP456",
  "timestamp": "2023-09-15T12:30:45Z",
  "notes": "Interested in Solutions Architect role",
  "entity_type": "SPONSOR_VISIT"
}

Implementation Priorities

  1. MVP (Must Have)

    • Badge printing system
    • Basic agenda app
    • QR code generation
    • Session attendance tracking
    • Sponsor lead capture

  2. Phase 2 (Should Have)

    • Profile customization
    • PIN-protected networking
    • Real-time agenda updates
    • Sponsor note-taking
    • Contest tracking

  3. Phase 3 (Could Have)

    • Builder ID integration
    • Analytics dashboards
    • Multilingual support
    • Offline capability

Success Metrics

We'll measure success by:

  • Reduction in check-in time vs. manual process
  • Percentage of attendees initializing profiles (target: >80%)
  • Number of networking connections (target: avg. 10 per attendee)
  • Sponsor lead capture efficiency (target: 3x previous methods)
  • Attendee satisfaction scores (target: >85% positive)
  • Number of Community Days adopting our platform (target: 5 in first year)

Open-Source Vision

This project will be open-sourced under Apache 2.0 license to enable:

  • Adoption by other AWS Community Days globally
  • Community contributions to enhance functionality
  • Showcase of serverless architecture best practices
  • Demonstration of AWS services in a real-world application

Clone this wiki locally