Telecom BSS database: choosing the data layer for subscriber, catalogue and usage workloads

Business support systems (BSS) are the commercial side of an operator: who the customer is, what they bought, used and owe. Operations support systems (OSS) run the network; this guide covers BSS.

A BSS estate holds several kinds of data, and they behave very differently:

• The customer and subscriber profile. One customer, several lines, each with its plan, add-ons, devices, preferences and consents. Read constantly by every channel, changed far less often.
• The product catalogue. Plans, bundles, offers and their eligibility rules, in Arabic and English. It changes with every campaign.
• Orders. A new line, a port-in, a SIM swap, an upgrade: a record that moves through steps and must not be lost half-way.
• Usage and balances. Rated usage arrives in large volumes; customers want to see their remaining data and minutes now, not after the next billing run.
• The financial record. Invoices, payments, adjustments and the ledger behind them. This is relational and transactional by nature.

In the Kingdom, apps for recharges, bundles and bills, online shops and partner channels carry much of an operator's customer contact. Three local factors shape the data layer.

• Peaks. Traffic follows campaigns, salary days, Ramadan and Eid. The layer is sized for those peaks, not an average day.
• Two languages. Catalogue, offers and notifications exist in Arabic and English, and search must work in both.
• Regulation and residency. Telecom services in the Kingdom are regulated by the Communications, Space and Technology Commission (cst.gov.sa). Subscriber data is personal data under the Personal Data Protection Law overseen by SDAIA (sdaia.gov.sa), and the National Cybersecurity Authority's controls (nca.gov.sa) apply to many operators' systems. Which rules apply is settled with your compliance owner; the design records where each copy of the data lives.

Interkey supports this work from Riyadh, with engineers who work in Arabic and English, from the first workload review to operating the platform after go-live.

Relatedcst.gov.sasdaia.gov.sanca.gov.sa

When the core strains, there are four common responses. Each has a cost.

• Scale the core up. Larger servers and more licences. Quick, but the billing run and the app still share one engine.
• Put a cache in front. Fast reads for the busiest screens. The weak points: stale data, and a cache that restarts empty during a campaign.
• Add an operational data layer beside the core. A NoSQL store holds the profile, catalogue and session data in the shape the channels read, kept in step with the system of record through change data capture. The core keeps the truth. Most estates end up here.
• Replace BSS modules one by one. A new catalogue or a new order system, each with its own data. Sound when a module is due for renewal anyway, but a programme of years.

Relatediblync

Couchbase is a distributed NoSQL database that stores JSON documents and key-value data, queried with SQL++. Interkey is a Couchbase technology partner and sells Couchbase Capella; the wider practice is on our Couchbase page. In a BSS design it maps to the high-read rows above:

• Subscriber profile as one document. Customer, lines, plans and consents read in one request by key, not a join across many tables. Our customer 360 page covers the single customer view in more depth.
• Catalogue with new attributes and no migration. A new bundle type adds fields; the Search service handles browse and keyword search. See the product catalogue page.
• Sessions and carts that expire on their own. Documents can carry an expiry time. The session store page covers that pattern.
• Memory first, durable when needed. Regular writes are acknowledged from memory and then written to disk; an order step that must not be lost can require a majority of nodes to hold it.
• Transactions where a flow needs them. ACID transactions are available through SQL++, for flows that change several documents together.
• Services scaled apart. Data, Query, Index, Search, Analytics and Eventing can run on nodes of their own, which Couchbase calls multi-dimensional scaling.

Relatedcustomer 360 pageproduct catalogue pagesession store page

A data layer is not a reason to move everything. Couchbase is the wrong answer for:

• The billing ledger. Multi-entity and audited, it stays on the relational system of record.
• Reporting over history. Months of usage scanned ad hoc belong on an analytical platform.
• A core that is actually fine. If it serves its load and growth is modest, tune it.
• No owner. A distributed cluster without a team, in-house or contracted, to operate it becomes an outage with a delay on it.

The assessment says so when that is the case.

We do not publish a price or a duration; both depend on the scope. The Couchbase licence follows the operating model: Capella is billed per node per hour, and self-managed Couchbase Server is a subscription priced by the number of production nodes. The engineering cost is driven by:

• the BSS workloads and channels in scope, more than data volume;
• how the core exposes changes, and how fresh the copy must be;
• the peak, which sets the node count;
• a second site, with its own nodes and indexes;
• where the data must be hosted, which decides between Capella and self-managed (see Capella or self-managed).

The review is fixed; the build is priced by workload, with vendor licensing shown separately.