ES /docs

Api::V1::IssuesController#create (avg 2481ms, max 2615ms)

Fix Plan: Api::V1::IssuesController#create Latency

Changes#

cupixworks: applications/issue-service/src/lambda/issue/create.ts#

  • What: getIssueWithFullInfo() 호출을 제거하고, 방금 write한 데이터 + findIssueType()에서 이미 조회한 issueType 객체를 in-memory로 조합하여 응답 구성. notification 호출을 Promise.all()로 병렬화.
  • Why: write-then-read anti-pattern으로 DynamoDB 3회 불필요한 재조회(~60-90ms), 순차 Lambda Invoke await(~200-1000ms) 제거
  • Lines: 98-111 — try 블록 내부 로직 변경

cupixworks: applications/issue-service/src/common/lambda-helper.ts#

  • What: LambdaClient를 모듈 스코프 singleton으로 변경. 각 함수에서 매번 new LambdaClient() 생성하던 것을 공유 인스턴스로 교체.
  • Why: warm start 시 connection 재사용으로 Lambda Invoke API 호출 latency 절감
  • Lines: 1-28 — 모듈 상단에 singleton 선언, 함수 내부 client 생성 제거

cupixworks: applications/issue-service/src/common/config.ts#

  • What: 모듈 스코프에 singleton DynamoDBClient 인스턴스 export 추가
  • Why: create.tsfindIssueType()에서 매번 new DynamoDBClient(dynamoDBClientConfig) 생성하는 것을 단일 인스턴스로 교체
  • Lines: 5-7 — config 하단에 client instance export

cupixworks: applications/issue-service/src/common/dynamodb-helper.ts#

  • What: getIssueWithFullInfo export는 유지하되, create handler에서 더 이상 호출하지 않음 (다른 Lambda handler에서 사용 가능성). getIssueTypById, getIssueTypByErrorCode 함수의 client 파라미터는 유지 (singleton을 caller가 전달).
  • Why: 기존 API 호환성 유지하면서 create 경로의 불필요한 read-back 제거
  • Lines: 변경 없음 (이 파일 자체는 수정하지 않음)

Acceptance Criteria#

  • create.ts에서 getIssueWithFullInfo import 및 호출이 제거됨
  • create.ts에서 응답 객체가 in-memory로 구성됨 (issueType 데이터 포함)
  • notification 호출이 Promise.all()로 병렬 실행됨
  • LambdaClientlambda-helper.ts 모듈 스코프 singleton으로 선언됨
  • DynamoDBClientconfig.ts에서 singleton으로 export되어 create.tsfindIssueType()에서 재사용됨
  • 기존 error handling (try-catch) 구조 유지
  • issue.issue_type.error_code?.startsWith("AGT") 조건 분기가 정상 동작

Tests#

  • 기존 테스트: applications/issue-service/src/code에 npm test 실행
  • 신규 테스트: 없음 (기존 동작 유지, 성능 최적화만)