{"id":"IL-0305","org":"Intercom","date":"2026-01-27","docs":[],"title":{"en":"Replicas of one Intercom Vitess shard hit 100% CPU and fell up to 2.2 hours behind, serving stale inbox data","ko":"Intercom 의 PlanetScale 샤드 하나에서 복제본이 CPU 100% 로 주 데이터베이스를 따라가지 못해 받은편지함에 최대 2.2시간 전의 데이터가 보였다"},"domain":["database"],"impact":{"scope":"Inbox reads for customers on one shard were slow and returned data up to 2.2 hours old; writes kept working","users":"fewer than 1% of Intercom customers","region":"US"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Because data is spread across many independent shards, the overload stayed on one shard and reached fewer than 1% of customers instead of the whole platform.","ko":"Intercom 은 이 장애가 샤딩한 데이터베이스 구조의 가치를 보여 줬다고 밝혔다. 데이터를 서로 독립된 여러 샤드에 나눠 두었기 때문에, 플랫폼 전체의 성능 저하가 될 수 있었던 일이 고객 1% 미만에 그쳤다."},"related":[],"sources":[{"url":"https://www.finstatus.com/us-hosting/incidents/01KGYCNMW8NH671AAGHE91BG33/write-up","kind":"official-status","archived":null}],"summary":{"en":"Intercom uses PlanetScale, built on Vitess, as its core database layer, with most high-scale data sharded across many database clusters. On January 27, 2026 two heavy workloads hit the same shard at once: the internal process that removes customer workspaces, which was running more concurrent deletion steps per app than usual with no rate limiting, and the ETL pipeline that reads the shard to sync data for analytics and reporting. From 17:03 UTC their combined load pushed both replicas of the shard to 100% CPU. The replicas fell behind the primary and replication lag grew to up to 2.2 hours, so reads for customers on that shard returned old data while writes kept working.\n\nAn alarm on an excessive worker message backlog declared an incident at 17:25 UTC. ETL processing was disabled at 18:25 UTC to reduce load on the shard. At 21:33 UTC the app deletion workers were scaled to zero, and ETL was carefully turned back on once monitoring showed stable metrics. At 22:09 UTC all replicas were back at healthy CPU levels, the lag had cleared and full recovery was confirmed. Intercom found no evidence of data loss or corruption.","ko":"Intercom 은 Vitess 위에 만든 PlanetScale 을 핵심 데이터베이스 계층으로 쓰고, 규모가 큰 데이터 대부분을 여러 데이터베이스 클러스터에 샤딩해 둔다. 2026년 1월 27일 한 샤드에 부하가 큰 작업 두 가지가 겹쳤다. 고객 워크스페이스를 지우는 내부 앱 삭제 작업이 속도 제한 없이 앱마다 평소보다 많은 삭제 단계를 동시에 돌렸고, 같은 때에 ETL 파이프라인이 분석과 보고에 쓸 데이터를 동기화하려고 같은 샤드를 읽었다. 두 작업의 부하가 복제본의 용량을 넘어 이 샤드를 맡은 복제본 두 대가 모두 CPU 100% 에 닿았다. 복제본은 주 데이터베이스의 변경 스트림을 따라가지 못했고, 복제 지연이 최대 2.2시간까지 늘었다.\n\n17:03 UTC 부터 복제 지연이 쌓였고, 17:25 UTC 에 메시지 백로그 알람이 울려 장애가 자동으로 선언되었다. 18:25 UTC 에 이 샤드의 부하를 줄이려고 ETL 처리를 껐고, 21:33 UTC 에 앱 삭제 워커를 0 으로 줄였다. 지표가 안정된 것을 본 뒤 ETL 을 조심스럽게 다시 켰다. 22:09 UTC 에 모든 복제본의 CPU 가 정상으로 돌아오고 복제 지연이 사라졌다. 영향은 Intercom 고객 1% 미만에 그쳤다. 쓰기는 내내 정상이었고, 고객 데이터가 사라지거나 손상된 증거는 없었다."},"trigger":{"en":"An internal app deletion process, running more concurrent deletion steps per app than usual with no rate limiting, and the ETL data pipeline both put heavy load on the same database shard at the same time.","ko":"내부 앱 삭제 작업과 ETL 파이프라인이 한 샤드에 겹쳤다. 앱 삭제 작업은 속도 제한 없이 평소보다 많은 삭제 단계를 동시에 돌렸고, ETL 파이프라인은 분석과 보고에 쓸 데이터를 같은 샤드에서 읽고 있었다."},"severity":"unknown","symptoms":["replication-lag","database-overloaded","high-latency"],"timeline":{"detected_after":"22m","resolved_after":"5h 6m"},"date_kind":"incident","detection":{"en":"An alarm on an excessive message backlog in a worker fired at 17:25 UTC and declared an incident automatically.","ko":"17:25 UTC 에 워커에서 메시지 백로그가 지나치게 쌓였다는 알람이 울렸고, 이 알람으로 장애가 자동으로 선언되었다."},"components":["database","database-replication"],"root_cause":"capacity","remediation":[{"text":{"en":"Disabled ETL processing to reduce load on the affected shard","ko":"18:25 UTC 에 영향받은 샤드의 부하를 줄이려고 ETL 처리를 껐다."}},{"text":{"en":"Scaled the app deletion workers to zero","ko":"21:33 UTC 에 앱 삭제 워커를 0 으로 줄였다."}},{"text":{"en":"Re-enabled ETL carefully once monitoring showed stable metrics","ko":"모니터링에서 지표가 안정된 것을 확인한 뒤 ETL 을 조심스럽게 다시 켰다."}}],"action_items":[{"text":{"en":"Increase the capacity of shards to leave headroom for unexpected load spikes","ko":"예상하지 못한 부하 급증에 대비할 여유를 두려고 샤드 용량을 미리 늘렸다."}},{"text":{"en":"Add rate limiting and resource controls to the app deletion process so it backs off when database load is high","ko":"앱 삭제 작업에 속도 제한과 자원 통제를 넣어 데이터베이스 인프라를 짓누르지 못하게 했다. 이제 워커는 용량 한도를 지키고, 데이터베이스 부하가 높으면 처리 속도를 늦춘다."}},{"text":{"en":"Review how background work such as ETL and maintenance tasks competes with customer-facing operations for database capacity","ko":"ETL 과 유지보수 작업 같은 백그라운드 작업이 운영 데이터베이스 용량과 어떻게 얽히는지 검토한다. 이런 작업이 고객이 쓰는 기능과 핵심 자원을 다투지 못하게 하는 것이 목표다."}},{"text":{"en":"Alert on replication lag earlier and link it to specific workloads","ko":"복제 지연을 더 일찍 잡고 특정 작업과 연결해 볼 수 있도록 알림을 보강한다."}},{"text":{"en":"Communicate proactively with affected customers in incidents with a limited blast radius","ko":"영향 범위가 좁은 장애에서도 영향받은 고객에게 먼저 연락하도록 절차를 고친다. 상태 페이지 전체에 올릴 일이 아니어도 영향받은 고객은 제때 소식을 받게 한다."}}],"contributing":["no-spare-capacity"],"recurrence_of":null,"symptoms_text":{"en":"From 17:03 UTC on January 27, 2026, a small subset of Intercom customers, fewer than 1%, saw inconsistent latency and stale data when reading from the platform. At 17:25 UTC an alarm on an excessive message backlog in a worker declared an incident automatically.\n\nFor those customers, new conversations did not appear in the inbox right after they were created, messages seemed not to send although they had been written, and changes to settings or data seemed not to take effect. Writes worked normally the whole time; only reads returned stale data.\n\nBehind this, both replicas of one database shard reached 100% CPU and could not apply the stream of changes from the primary fast enough. Replication lag grew steadily and reached up to 2.2 hours, so customers on that shard were reading data more than two hours old.","ko":"2026년 1월 27일 17:25 UTC 에 메시지 백로그가 지나치게 쌓였다는 워커 알람이 울려 장애가 자동으로 선언되었다. 일부 고객의 받은편지함에서 지연이 들쭉날쭉했고 오래된 데이터가 보였다.\n\n고객 쪽에서는 대화를 만들어도 받은편지함에 바로 나타나지 않았다. 메시지가 보내지지 않은 것처럼 보였지만, 실제로는 제대로 저장되었다. 설정이나 데이터를 바꿔도 적용되지 않은 것처럼 보였다. 쓰기는 장애 내내 정상이었고, 영향은 읽기에서 오래된 데이터가 나오는 것에 그쳤다.\n\n데이터베이스 쪽에서는 17:03 UTC 부터 한 샤드의 복제본 CPU 가 오르며 복제 지연이 쌓이기 시작했다. 이 샤드를 맡은 복제본 두 대가 모두 CPU 100% 에 닿았고, 주 데이터베이스에서 오는 변경 스트림을 따라가지 못해 백로그가 쌓였다. 복제 지연은 꾸준히 늘어 최대 2.2시간까지 갔다."},"updated_at":"2026-11-14T12:33:55.900998Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0305","org_slug":"intercom"}