COEXR
An early-stage social fitness product intended to turn nearby workout plans into shared, privacy-aware experiences.
A system shaped by real-world constraints.
COEXR's planned first-release loop connects a host publishing a workout with privacy-aware nearby discovery, clear participation states and a shared place for activity updates and media.
The supplied product brief defines discovery, workout lifecycle, location matching, media, reporting and blocking as MVP direction. The implemented source is currently focused on the platform foundation: passwordless identity, token lifecycle and asynchronous email delivery.
Where I contributed.
- Co-founding the product direction and defining the intended host-to-participant loop with location, commitment, privacy and trust requirements.
- Engineering the Spring Boot foundation across passwordless authentication, access and refresh tokens, PostgreSQL migrations and Redis-backed verification state.
- Establishing shared RabbitMQ event contracts, confirmed publication and a separate notification worker for email delivery.
What made the work difficult.
- The intended product must eventually support useful nearby discovery without exposing precise personal or meeting-point information before the appropriate participation state.
- The identity flow crosses ephemeral OTP state, persistent session state and asynchronous email delivery without creating ambiguous authentication outcomes.
- The API and notification worker need contracts that can evolve without allowing their event shapes to drift.
What mattered technically.
Passwordless identity foundation
Implemented email OTP authentication with hashed Redis state, bounded expiry, resend cooldown, capped verification attempts and single-use cleanup after successful verification.
Short-lived access, rotating refresh
Issued RSA-signed access tokens with explicit issuer, audience, expiry, token ID and roles. Refresh tokens are cryptographically random, stored only as hashes and rotated transactionally; detected reuse revokes the user's active refresh tokens.
Versioned event contracts
Defined a shared contracts module so the API and worker compile against the same event identity, routing key, correlation metadata and versioned type mapping.
Confirmed event publication
Published persistent RabbitMQ messages and waited for broker acknowledgement, treating rejected, unroutable or unconfirmed events as application failures instead of assuming delivery.
Separated notification delivery
Moved email rendering and Resend transport into a dedicated worker behind a durable queue and dead-letter topology, keeping provider work outside the authentication request boundary.
Migration-led persistence
Used Flyway migrations to evolve PostgreSQL user verification, account state and refresh-token records as the identity model developed.
Correctness beyond the happy path.
- Bounded OTP lifetime, resend cooldown, capped attempts and single-use deletion limit stale or repeated verification work.
- Stateless API authorization validates token issuer and audience, maps roles explicitly, restricts administrative paths and permits credentialed requests only from the configured frontend origin.
- Hashed refresh-token storage, transactional rotation and replay-triggered revocation contain reuse without persisting bearer credentials in plaintext.
- Persistent messages, publisher confirmations, durable queues and a dead-letter path establish explicit failure boundaries between the API and notification worker.
What the work made possible.
- Keeping product direction visibly separate from implemented behavior prevents early roadmap requirements from being presented as shipped capability.
- Establishing identity and event boundaries first gives later workout, location, media and safety modules stable integration points.
Technology should support the system, not become the story.
Java · Spring Boot · PostgreSQL · Flyway · Redis · RabbitMQ · React Native · Expo · Thymeleaf · Resend