Event RSVP & Media Platform

Guests needed to RSVP across several ceremonies on one form, see who else in their family group was attending, and upload event photos without creating an account. The backend is Express on Firestore, with a deliberate split: the Firestore Client SDK handles family and guest records, the Admin SDK handles photo metadata and moderation, so the two concerns never share a trust boundary by accident. Every photo upload gets processed into three versions (original, a 1200px compressed copy, and a 300x300 thumbnail) before it reaches Cloudflare R2, so the gallery never serves a multi-megabyte original to a guest scrolling on mobile data.

The event needed a controlled guest flow across multiple ceremonies, reliable concurrent RSVP writes from family groups submitting at the same time, and a photo gallery that would not become an expensive or unbounded storage liability, all without exposing administrative data or storage credentials.

Frontend, backend, deployment, guest workflow, photo pipeline, and storage infrastructure (Terraform).

• React
• Vite
• Express.js
• Firebase
• Cloudflare R2
• Terraform

• • Multi-event RSVP across several ceremonies in one form, with per-family attendance tracking
• • Firestore transactions so two family members RSVPing at the same moment never clobber each other's write
• • Three-version image pipeline (original, 1200px compressed, 300x300 thumbnail) ahead of every R2 upload
• • Terraform-provisioned R2 bucket with CORS scoped to the production domain and local dev ports only

The client and Express API deploy as separate production concerns with storage credentials kept server-side. R2 bucket creation, the custom domain, and CORS rules are defined in Terraform rather than clicked together in a dashboard, so the storage layer is reproducible if it ever needs to move.

• • Ran the real event’s RSVP and media flow live at marrying-maharaj.co.za, independently verifiable via the link above
• • Guest validation and media uploads handled with no exposed storage credentials
• • Photo storage costs stayed negligible across the event by compressing every upload before it reached R2, instead of storing originals unprocessed

Guest validation gates every RSVP and upload action, storage credentials never reach the browser, and the photo pipeline strips and rewrites image metadata during the resize step rather than passing the original file through untouched. The client project remains private.

• • Coordinating guest identity with RSVP state across family groups without an account system to anchor it
• • Keeping concurrent writes consistent when several guests in the same family RSVP within seconds of each other
• • Sizing the image pipeline so a phone-camera photo and a DSLR export both land at a predictable storage cost

• • Splitting Firestore's Client and Admin SDKs by concern (guest data vs. photo data) made the trust boundary explicit instead of implicit
• • Upload flows need a processing step before storage, not just an access-control check at the door
• • Private client work can still document real architecture without exposing guest data or the client's identity

• Live production site
• Case study
• Architecture