실무 문제

캐싱이라는 것이 그냥 얼마나 캐싱할지 시간만 잘 걸어두면 되는거라고 생각을했다. 하지만 뭐를 키를 뭐로 잡을 것인지, 데이터가 변경이 일어났을 때 원본 데이터와 동기화를 어떻게 맞출 것인지 등 고려할 것이 많았다. 그래서 이번에는 이론적인 것보다는 경험으로 배운 것들을

현업에서의 개발은 학습 목적의 개발과 차이가 난다고 느껴지는 몇몇 포인트가 있다. 그런 것들 중 하나가 운영을 위한 코드나 기능들이 들어가야할 때가 있다는 점이다. 이번에도 주식 예언과 관련된 이벤트를 만들다가 사용자들의 데이터 변경 히스토리들을 다 저장해서 나중에 필

작성 이유 회사에 들어오고 3주차였나 4주차였나 처음으로 냈던 에러가 batch job 관련 된 것이었다. 30만명을 대상으로 푸시 / 알림을 발송하는 기능이었는데 아침에 모니터링을하며 로그를 보니 2명에게만 발송되었다 (꿈인줄 알았다). Batch를 정말 Batch

내가 주로 담당하는 기능들은 이벤트로 무료 주식을 나눠주는 기능이다. 그런데 이 무료 주식들에 대해 취소해달라는 CS가 생각보다 많이 들어온다 (소수점 주식을 보는게 거추장스럽거나, 다른 증권사 직원들인 경우). 이 CS 때문에 컨텍스트 스위칭도 자주 발생하고, cs

현재 팀의 특성상 기존 코드에 새로운 기능을 덧대는 일보다는 항상 새로운 기능을 만들고 나가는 일이 많았다. 하지만 이번에는 기존 코드가 조금 변경되어 기능이 나갔는데, 기존 기능과의 하위 호환성을 고려하지 않고 배포가 나갈뻔 했다. 배포를 할 때는 서버/프론트의 배포

가위바위보 이벤트를 만들면서 재밌는 문제가 있었고, 다른 분들의 도움으로 해결할 수 있었다. 그 문제와 해결 과정이 재밌었다. 우선 가위바위보 이벤트는 다른 사람에게 링크를 보내서 링크를 받은 사람이 경기에 참여함으로서 두 사람이 가위바위보를 하게된다. 여기서 제약 조

가위바위보 이벤트가 생각보다 잘되었고, 이걸 조금 더 개선해보는 아이디어 중 하나가 가위바위보 몇등을 했는지를 보여주는 리더보드를 만드는 것이었다. 랭킹을 보여주려면 레디스의 zSet을 쓰면 된다고 생각했다. 하지만 문제는 과거 데이터까지도 다 반영해서 랭킹을 보여줘야

가위바위보 이벤트를 하면서 푸시를 보낼일이 많이 생겼다. 예를 들어 가위바위보에 승리하고 나면 1승을 추가로 하면 또 다른 무언가를 얻을 수 있다고 푸시를 보낸다. 처음에는 이런 것들이 그렇게 많지 않아서 코드에서 직접적으로 푸시를 보내는 코드를 추가했었다. 하지만 이

우테코를 할 때 db 패스워드, 시크릿 키 같은 것들을 저장하기 위해 서브모듈을 쓰는 팀이 많았다. 본 프로젝트 레포 (public) -> 민감 정보를 저장한 레포 (private) 이렇게 구성하는 형식이다. 그때 우리 팀에서는 암호화하는 방식을 써서 서브모듈을 쓸 일

조회가 빈번하게 발생하는 서비스의 경우 캐시를 이용해서, DB를 직접 조회하는 쿼리 개수를 최소화하고 DB 부하를 줄인다. 하지만 우연의 일치로 한참 트래픽이 높은 시간에 캐시가 만료되어있다면 어떻게 될까?트래픽이 많지 않다면 캐시 미스가 났을 경우 하나의 요청이 db