🛠 Tech Assessment: Church Member & Service Management System
Objective
Design and implement a serverless system to manage member and service activity information for a local branch of The Church of Jesus Christ of Latter-day Saints. The system should be secure, scalable, cost-efficient, and demonstrate expertise with AWS SDK for Java, serverless architecture, and infrastructure as code (CloudFormation).
Entities and Fields
Member 1️⃣
Represents a church member.
- member_id
- UUID, primary key
- first_name
- String
- last_name
- String
- date_of_birth
- Date
- email
- String
- phone_number
- String
- ward
- String, e.g., “Oakland 1st Ward”
- calling
- String, optional, e.g., “Teacher”, “Relief Society President”
- created_at
- Timestamp
- updated_at
- Timestamp
ServiceActivity 2️⃣
Represents a service or volunteer activity.
- activity_id
- UUID, primary key
- name
- String, e.g., “Community Clean-up”
- description
- String, optional
- date
- Date
- location
- String, optional
- leader_id
- UUID, foreign key → Member.member_id
- created_at
- Timestamp
- updated_at
- Timestamp
ActivityParticipant 3️⃣
Represents members participating in a service activity.
- participant_id
- UUID, primary key
- activity_id
- UUID, foreign key → ServiceActivity.activity_id
- member_id
- UUID, foreign key → Member.member_id
- role
- String, optional, e.g., “Organizer”, “Helper”
Attachment 4️⃣
Represents files related to members or service activities (stored in S3).
- attachment_id
- UUID, primary key
- owner_type
- Enum: MEMBER or ACTIVITY
- owner_id
- UUID, references Member.member_id or ServiceActivity.activity_id
- filename
- String
- s3_key
- String, path in S3 bucket
- uploaded_at
- Timestamp
Relationships
- Member → ServiceActivity: 1-to-many (a member can lead many activities).
- ServiceActivity → ActivityParticipant → Member: many-to-many (members can participate in multiple activities).
- Member or ServiceActivity → Attachment: 1-to-many (files linked to member or activity).
AWS Architecture Components
AWS Lambda (Java)
Handles all CRUD operations for members, activities, participants, and attachments. Uses AWS SDK for Aurora Serverless and S3. Scales automatically, cost-efficient.
Amazon API Gateway
Exposes RESTful endpoints:
- /members (GET, POST, PUT, DELETE)
- /activities (GET, POST, PUT, DELETE)
- /activities/{id}/participants (GET, POST, DELETE)
- /attachments (POST, GET)
Aurora Serverless v2 (MySQL)
Stores relational data: members, service activities, participants. Data API allows Lambda to query securely without persistent connections.
Amazon S3
Stores attachments and optional documents. Accessed securely via Lambda and AWS SDK.
CloudFormation
Deploys Lambda functions, API Gateway, Aurora cluster, S3 buckets. Infrastructure as Code ensures reproducibility.
CloudWatch + AWS Budgets
Logs, metrics, and cost monitoring. Ensures system runs cost-efficiently (<$1/month for demo scale).
API Flow Example
- Admin posts a new service activity to /activities.
- API Gateway routes the request to Lambda CreateActivityLambda.
- Lambda inserts activity into Aurora Serverless. Optionally uploads documents to S3. Returns a JSON response with activity ID.
- Members are added via /activities/{id}/participants.
- Logs are automatically sent to CloudWatch, costs monitored via Budgets.
Demonstrated Skills
- AWS SDK for Java: Aurora Serverless, S3, Lambda integration.
- Serverless architecture: event-driven, cost-efficient backend.
- Relational data modeling: members, activities, participants, attachments.
- Infrastructure as Code: CloudFormation deployment.
- Cost management: Free-tier and auto-pause usage strategies.
- Secure, scalable APIs: RESTful API with proper authorization.
Links