
리액티브 시스템은 클라이언트의 요청에 빠르게 반응하고, 예측 가능한 응답을 제공하는 반응성(Responsiveness) 중심의 시스템이다. 단순히 빠르기만 한 시스템이 아니라, 다양한 상황에서도 일관된 응답성과 높은 신뢰성을 유지할 수 있도록 구성된다.리액티브 시스템의

리액티브 프로그래밍을 이해하기 위해 반드시 짚고 넘어가야 할 개념이 바로 리액티브 스트림즈(Reactive Streams) 이다. 이는 리액티브 라이브러리를 구현할 때 따라야 할 표준 인터페이스 사양으로, 비동기 스트림에서 데이터의 흐름을 제어하고, Back Press

Blocking I/O는 전통적인 방식의 입출력 처리 모델로, 하나의 스레드가 특정 I/O 작업(예: 파일 읽기, 외부 HTTP 요청 등)을 수행하는 동안 해당 작업이 완료될 때까지 아무런 다른 작업도 수행하지 못하고 대기하는 방식이다. 예를 들어, RestTempla

함수형 인터페이스는 오직 하나의 메서드만 가지는 인터페이스이다. 자바에서는 이 인터페이스를 통해 함수를 값처럼 전달할 수 있으며, 람다 표현식의 대상이 되는 타입이기도 하다. 자바 8 이전에는 익명 클래스를 사용해야 해서 코드가 복잡하고 길어졌다. 예를 들어 두 수를

Reactor는 Reactive Streams 사양을 구현한 비동기 논블로킹 스트림 처리 라이브러리로, 리액티브 프로그래밍을 자바에서 구현할 수 있도록 지원하는 핵심 도구이다. Spring 진영에서 개발한 이 라이브러리는 특히 Spring WebFlux와 함께 자주 사

리액티브 프로그래밍은 비동기 데이터 흐름을 다루는 데 초점을 맞춘 패러다임이며, Java 진영에서는 Reactor가 그 핵심 라이브러리 역할을 담당한다. 특히 Mono와 Flux라는 두 가지 주요 타입은 리액티브 흐름을 정의하고 조작하는 데 핵심이 된다. 이번 글에서는

리액티브 프로그래밍에서 흔히 마주치는 개념 중 하나가 바로 Cold와 Hot이다. 이 용어는 데이터 스트림의 생성 방식과 구독 시점에 따른 처리 차이를 설명하는데 사용된다. 단어 자체는 어렵지 않지만, 실제 동작 방식은 충분히 실험해보지 않으면 오해하기 쉽다. 이 글에

리액티브 프로그래밍의 세계에서는 데이터가 끊임없이 비동기적으로 흐르며 소비자에게 전달된다. 이 과정에서 생산자(Publisher)가 소비자(Subscriber)의 처리 속도보다 너무 빠르게 데이터를 발행하면 어떻게 될까? 메모리 누수나 과부하, 시스템 다운 등의 문제가

Reactor는 대부분 데이터가 안에서 바깥으로 흘러가는 구조(Pull)를 따르지만, 때로는 외부에서 임의로 데이터를 Push해야 할 때가 있다. 예를 들어, 외부에서 전달된 콜백 결과나 수동으로 제어하는 신호를 스트림에 넣어야 하는 상황이다. 이럴 때 사용하는 것이

CPU는 여러 개의 \*\*코어(Core)\*\*로 구성되어 있으며, 각 코어는 연산을 수행하는 최소 단위인 물리적 스레드를 갖는다. 이 물리적 스레드는 실제로 명령어를 처리하는 하드웨어 단위로, \*\*병렬성(Parallelism)\*\*과 직결된다.예를 들어, "4

Reactor의 Context는 한마디로 말하면 Operator 체인 사이에서 전파되는 key-value 기반의 저장소다. 이 저장소는 일반적인 컬렉션과는 다르게 다음과 같은 특징을 갖는다:불변성(Immutable): 연산자 간 충돌을 방지하고 안전한 상태 전달을 위해

Reactor 기반의 리액티브 프로그래밍에서 발생하는 오류는 일반적인 스택트레이스로는 원인을 추적하기 어려운 경우가 많다. 특히 연산자 체인이 복잡해질수록 에러의 지점을 정확히 파악하기 어려워 디버깅이 힘들 수 있다. 이러한 상황을 보완하기 위해 Reactor는 디버깅

리액티브 스트림의 테스트는 단순한 값 검증을 넘어 신호(Signal)의 흐름과 비동기 처리 과정까지 정확하게 검증해야 한다. 이때 가장 강력한 도구가 바로 \*\*Reactor의 StepVerifier와 TestPublisher\*\*이다. 이 장에서는 두 도구의 핵심

리액티브 프로그래밍을 학습하거나 테스트 코드를 작성하다 보면 어떤 Flux는 결과가 곧바로 출력되지만, 어떤 Flux는 아무것도 출력되지 않고 종료되는 상황을 마주하게 된다.이 차이는 결국 Flux가 언제 데이터를 emit하느냐, 즉 동기적으로 실행되느냐 비동기적으로

Reactive Programming에서는 다양한 오퍼레이터를 통해 Mono 또는 Flux 시퀀스를 생성할 수 있다. justOrEmpty는 just 오퍼레이터의 확장 개념으로, 값이 null인 경우에도 NullPointerException을 발생시키지 않고 onCom

리액티브 프로그래밍에서 filter, skip, take, next 같은 오퍼레이터는 데이터 스트림에서 원하는 데이터만 골라내거나 흐름을 제어할 때 사용된다. 이 글에서는 각 오퍼레이터의 개념과 실제 사용 예제를 기반으로 동작 방식을 정리하고, 실행 시 주의할 점도 함

map, flatMap, concat, merge, zip: Flux 흐름을 변환하거나 결합. and: 완료 신호만 모아서 후처리할 때 사용. collectList, collectMap: 전체 결과를 하나로 모아 Mono로 변환할 때 사용. | 오퍼레이터 |

Reactor에서는 Upstream Publisher에서 emit되는 데이터를 변경하지 않고,로그 출력, 상태 확인, 디버깅, 로직 트리거 등의 부수 효과(side-effect)를 수행하기 위한 오퍼레이터로 doOnXXX() 계열을 제공한다.이 오퍼레이터들은 대부분 C

리액티브 스트림에서는 데이터 흐름 중 발생하는 에러를 제어하기 위해 다양한 에러 처리 오퍼레이터를 제공한다. 이 오퍼레이터들은 에러 발생 시점에 따라 대체 값을 emit하거나, 시퀀스를 중단하거나 재시작하는 방식으로 유연하게 대응할 수 있도록 돕는다. 1. error

elapsed()는 Flux에서 emit되는 각 데이터 항목마다 이전 항목이 emit된 이후 경과한 시간(ms) 을 측정하여 함께 emit하는 오퍼레이터이다.각 요소는 Tuple2<Long, T> 형태로 전달되며, 첫 번째 값(T1)은 경과 시간, 두 번째 값(T

buffer(n)은 스트림에서 emit되는 데이터를 n개 단위로 묶어 List 형태로 전달하는 오퍼레이터이다. 마지막 남은 데이터도 모아서 emit한다.bufferTimeout(n, d)는 다음 조건 중 하나라도 충족되면 데이터를 List로 emit한다:n개의 데이터

connect(), autoConnect(), refCount()리액터(reactor)의 Flux 스트림은 기본적으로 cold하다.하지만 .publish()를 사용하면 이를 hot stream(ConnectableFlux)으로 변환할 수 있다. 여기에 연결 시점을 제

Spring WebFlux는 리액티브 웹 애플리케이션을 구현하기 위해 Spring 5부터 도입된 논블로킹(Non-Blocking) 기반의 웹 프레임워크이다.기존 Spring MVC는 Servlet 기반의 블로킹 I/O 구조로, 하나의 요청을 처리하는 동안 하나의 스레드

이번 글에서는 그 중에서도 애너테이션 기반 WebFlux 컨트롤러에 집중하여, 단순히 Mono를 반환한다고 해서 자동으로 논블로킹이 보장되는 것은 아님을 설명하고, 실제로 논블로킹 구조를 설계하는 방법을 코드 중심으로 다룬다.Spring MVC 스타일에 익숙하다면 We

Spring WebFlux는 애너테이션 기반 프로그래밍 모델과 함께, 함수형 엔드포인트를 기반으로 하는 프로그래밍 모델도 지원한다.WebFlux의 함수형 엔드포인트는 들어오는 요청을 처리하기 위해 HandlerFunction이라는 함수형 기반의 핸들러를 사용한다.서블릿

R2DBC는 "Reactive Relational Database Connectivity"의 약자로, 리액티브 프로그래밍 방식으로 관계형 데이터베이스에 접근할 수 있도록 설계된 비동기 논블로킹 API 표준 사양이다.기존 JDBC는 스레드당 하나의 커넥션을 사용하고, 쿼

onErrorResume은 리액티브 스트림에서 에러가 발생했을 때, 해당 에러를 Downstream으로 전파하지 않고 대체 Publisher를 통해 정상적인 흐름을 이어가는 방법이다.특정 예외에 대해 분기 처리하거나, 에러 내용을 감싸서 새로운 응답을 만들 수 있다.에

WebClient는 Spring 5에서 도입된 비동기 HTTP 클라이언트이다. 함수형 API를 제공하며, Non-Blocking 요청을 처리할 수 있도록 설계되었다. 내부적으로는 Netty 기반의 Reactor Netty를 사용하며, 기존 RestTemplate과 달리

웹 애플리케이션에서 실시간 데이터를 사용자에게 전달하고자 할 때, 우리는 흔히 WebSocket을 떠올린다. 하지만 양방향 통신이 반드시 필요한 상황이 아니라면, 더 간결하고 HTTP 친화적인 방식으로 실시간 스트리밍을 구현할 수 있다. 바로 SSE(Server-Sen

실시간 데이터를 브라우저에 전달하는 기술은 다양하다. 그중에서도 Spring WebFlux 기반으로 Server-Sent Events(SSE)를 구현하는 방식은 비교적 간단한 구조로도 반응형 스트리밍을 완성할 수 있는 강력한 방법이다. 이 글에서는 Spring WebF