두 팀이 자신의 애플리케이션에 특화된 데이터를 구성해야 한다면 키-이름이 충돌할 가능성이 있다. 고객 관리 시스템을 개발하는 팀은 개인 가전, 의류, 스포츠 용품 등 고객이 구매한 제품의 유형 정보를 관리하고자 할 것이다. 이 팀은 자신들의 제품 유형 키로 Prod란 접두어를 사용하기로 결정했다. 주문 관리 시스템을 만들고 있는 다른 팀은 좀 더 세밀한 수준에서 제품을 관리할 필요가 있다. 개인 가전 같은 넓은 범위의 분류 대신 iPhone5 32GB 같은 특정 제품을 관리해야 하며, 이들 역시 Prod란 접두어를 사용하기로 했다.

이렇게 되면 아마도 다음과 같은 문제가 발생할 것이다. 두 애플리케이션이 같은 고객 데이터, 즉 같은 고객 ID를 사용한다고 가정해보자. 고객 관리 시스템 개발팀은 Prod:12986:name이란 키를 생성해서 이 키에 가전제품이란 값을 할당했다. 반면에 주문 관리 시스템 개발팀은 고객이 주문한 마지막 상품을 관리하고자 Prod:12986:name이란 키를 생성해 iPhone5 32GB란 값을 할당했다.

이 상황에서는 둘 중 한 애플리케이션이 쓴 마지막 값이 이 키의 값으로 설정된다. 다른 애플리케이션이 이 데이터를 조회한다면 틀린 값을 읽을뿐만 아니라 원하던 값의 범위도 벗어날 것이다.

이름공간은 키에 추가로 접두어를 정의하여 이 문제를 간단히 해결한다. 고객 관리 시스템 개발팀은 custMgmt라는 이름공간을 생성하고 주문 관리 시스템 개발팀은 ordMgt라는 이름공간을 생성해 놓는다면 각각의 이름공간에 모든 키와 값을 저장할 수 있게 된다. 이전에 문제가 됐던 키는 이제 두 개의 고유 키가 되었다. 하나는 custMgr: Prod:12986:name이고, 나머지 하나는 ordMgr: Prod:12986:name이다.