Redis pub/sub은 기본적으로 채팅이 유실될 수 있는 문제가 있다.케이스를 하나씩 살펴보자구독자 연결 상태 문제구독자가 연결이 끊겨지거나 네트워크로 인해 메시지를 받을 수 없는 경우 메시지가 유실된다Redis의 비영구 저장Redis Pub/Sub은 메시지를 휘발

예전에 서버에서 oome가 터졌었다 예전에 한번 터졌던 적이 있어서 jar파일 만들 때 이런 옵션으로 oome가 터지면 자동으로 /tmp에 힙 덤프 파일을 만들어 놨다 물론 덤프 파일 만들고 자동으로 서버 다시 동작하게도 해놨다 어려운건 아니고 elastic beans

기존 인덱스 적용 후

소개팅 주선 서비스에서 프로필을 입력하는 기능(이하 프로필 설문)이 있다.다른 도메인보다 프로필을 입력하는 질문 수가 많을 수 밖에 없다페이스북은 사용자가 자기소개를 작성하고 사진과 신상정보를 추가하도록 하면서 사용자가 참여하도록 하고 심리적인 보상을 제공한다 페이스북

우리 서비스는 소개팅 서비스로 유저와 유저가 상호작용 하기 때문에 url이나 message body에 상대방의 userId가 들어가는 경우가 종종 있다 예를들어 "/v1/어쩌고/저쩌고/{user-id}" 를 사용해서 추천, 매칭이 이미 진행된 상대방의 프로필을 볼 수

채팅 기능을 구현하려 한다우리 서버는 오토스케일링으로 최대 2대까지 ec2가 늘어날 수 있다, 로드밸런서로 부하 분산을 한다 잦은 일은 아니지만 실제로 유저들이 많이 몰리는 시간대에 2대까지 늘어난다A와 B가 채팅을 하는 상황이라고 생각해보자 A클라이언트는 1번서버에

예전에 인가, rate limit 을 적용하는 과정에서 이 일련의 과정을 aop로 해서 컨트롤러에 어노테이션을 달아서 해결할 수 없을까? 라는 생각으로 시작 했다가 그냥 인터셉터에 로직을 넣고 거기서 커스텀 어노테이션을 사용하는게 더 좋을 것 같아서 무산되었었다 rat

예전에 처음 개발을 시작하고 첫 프로젝트를 했을 때, 소셜 로그인을 위해서 rest template을 사용했다 하지만 코드가 너무 복잡해 지고 Feign client라고 스프링 부트의 어노테이션을 활용하여 정말 깔끔하게 사용할 수 있다 해서 사용했었다지금 시점에서 그때

예전에 그룹 스터디 참여 로직에 Pessimistic Lock(이하 비관적 락)을 이용하여 동시성 이슈를 처리했었다링크: https://velog.io/@wellbeing-dough/%EC%8A%A4%ED%94%84%EB%A7%81-%EB%B6%80%ED%8A

예전에 새벽1시에 슬랙에 뭐하는지 모르겠는데 어떤 유저가 추천 단건조회에 계속 요청을 보냈었다 그래서 무서워서 급하게 알아보고 RateLimit을 걸었다어떻게 1초동안 10번을 보낸건진 모르겠다...그리고 중복 요청 이슈가 발생하여 알림톡이 두번 나갔는데 이것도 유저

00시부터 09시까지 No Xlog profile collected 가 뜨면서 XLog가 프로파일링이 안되는 문제가 발생했다그리고 메서드 프로파일링도 아무리 옵션을 잘 줘도 실행이 안된다...구글링을 해보니 scouter server collector와 scouter

저번달에 새벽1시였나 서버가 갑자기 죽었다 깜짝놀라서 기존 서버를 내리고 새로운 서버를 배포 했다 그러니 잘 돌아갔다...하지만 이유를 알 수 없었다... 기존 서버를 없에버려서... 그때 실제 유저들이 돈을 내고 사용하고 있던 서비스라서 너무 놀라서 일단 서버를 복구

1. 문제상황 우리는 jwt를 사용해서 인가를 하고 interceptor에서 한다 그래서 WebConfig.class에서 이렇게 하나하나 인가가 필요한 url을 달아서 InterceptorRegistry를 사용하여 인터셉터를 추가한다 이렇게 하니까 각 패키지에 흩어

플젝이 끝나고 시간이 남았다 객체지향의 사실과 오해를 읽고 추상화, 다형성에 관심이 많아졌고 내가 했던 플젝에서 적용할만한 곳이 있을까 둘러보다가 좋은 소스를 찾았다 우리 서비스는 카카오, 네이버 로그인을 지원한다 대부분의 소셜 로그인 써드파티 제공 업체는 회원가입(

문제점 우리 서비스의 1기 매칭 버전1에서 서로 매칭을 해주는 과정에서 생겼던 이슈이다 매칭 과정을 이렇다 트랜잭션 시작 남자 유저 데이터 가져옴 여자 유저 데이터 가져옴 남자, 여자 매칭 있는지 검증 -> 매칭이 이미 존재하면 예외 남자에게 추천된 데이터 가져옴 ->

하나의 서비스 레이어가 다른 모든 repository와 다른 서비스 레이어를 의존함 -> 스파게티 코드 이렇게 되자 서비스 클래스의 메서드 하나하나가 책임과 역할이 커지고 서비스 레이어의 클래

급하게 요구사항이 변경되었고 개발일정을 넉넉하게 말씀드렸다요구사항이 변경됨에 따라 ALTER TABLE을 할 일이 생겨서 기능 구현을 어느정도 끝마치고 RDS에 ALTER TABLE을 했는데 무슨 해당 쿼리가 끝나지 않고 계속 돌아가는 것이였다근데 또 DML작업은 가능

1. 문제상황 study hub 서버 개발을 하면서 유저가 스터디에 참여를 하면 스터디 게시글(studyPost)에 remainingSeat(잔여석)이 -1되어야 한다 멀티 쓰레드나 서버가 여러대일 경우에는 studyPost의 동시성 처리를 해야 동시에 참여한 유저가

문제상황 술 조회 기능 중 지방마다 특색 있는 전통주 특성상, 위치 기반으로 조회하는 기능의 필요성을 느껴, 위도 경도 값을 활용하여 유저가 확대한 좌표 안에 있는 전통주 주조장 조회 기능을 개발했다 우리 서비스에서 가장 성능이 안나오는 부분이다 왜와이? 해당 페이지에

문제 상황 우리는 스터디 게시글을 조회할때 페이지네이션을 사용하여 10개씩 조회한다