Architecture Decisions: Mixed Reactive/Non-Reactive & SSE
1. Why Mixed Reactive / Non-Reactive Architecture The project originally attempted a fully reactive stack across all services, but was […]
1. Why Mixed Reactive / Non-Reactive Architecture The project originally attempted a fully reactive stack across all services, but was […]
1. Why Kafka Over Other Message Brokers AdventureTube uses Apache Kafka for asynchronous messaging between microservices. Here’s why Kafka was
1. Correct Design of Controller and Service Principle: Thin Controller, Fat Service Controllers should only handle HTTP concerns: routing, request/response
Series Navigation: Introduce AdventureTube Microservice Hub Part 1: Architecture Overview & Design Patterns Part 2: Development Environment & Debugging Part
1. Backend — Implemented (2026-03-09) Status: COMPLETED — All Tests Passing Merged to main via commit 99ea583 (branch feature/kafka-job-status-sse). 42
Problem When auth-service called member-service and got a 4xx error (e.g. USER_NOT_FOUND on second delete), the circuit breaker treated it
1. Service Connection Pattern The first architecture decision for a microservice platform: how do services connect to each other? Everything
Registration Flow POST /auth/users iOS App → AuthController → AuthService.createUser() → Google API (verifyIdToken) → Member-Service (emailDuplicationCheck) → Member-Service (registerMember)
Overview AdventureTube utilizes a backend system comprised of microservices. Each microservice is independently built as a Docker container and managed
This page is the master technical reference for the AdventureTube backend platform — a Spring Cloud microservices system deployed on