Watch keynotes and sessions from MongoDB.live, our virtual developer conference.

Which Design pattern works best for the problem here

We have been asked to design a solution for a leading cellular company with more than 40 Million customers to cater to the need of showing up the call and charges details.

Write :

There would be a nightly batch refreshing call and charges details for all customers into Mongo DB

Read:

Mongo DB needs to support data for an online system.

  • Customer can search based on From date and To date
  • Customer can select one or multiple past bills (Bill Date) to see the call details

There are multiple billing cycle and the customer can choose to part of any billing cycle.

The customer can change the billing cycle once year.

Retention

Data needs to be retained for 1 year and then data needs to be Purged.

Volumetrics

Call

Avg Call items per day per customer = 20

So for 365 days and for all customer line items = 20 365 40 = 292 Billion

Data

Data usage line item per day per customer = 10

So for 365 days and for all customer line items = 10 365 40 = 146 Billion

Header

Customer_number

Customer Name

Customer Address

Customer Mobile Number

Bill period

Bill date

Tarif Plan name

Previous Dues

Payments

Current Charges

Total Amount Due

Due Date

Summary of Current Charges

  1. Monthly Rental
  2. Voice Call Charges
  3. SMS Charges
  4. Data Services

Subtotal

Taxes

Total Current Charges

Call Details

Date

Time

Called Number

Duration

Units

Amount

Data Usage details

Date

Time

Units in (MB)

Amount

Points to Ponder

  • Do we keep the header information and call details in same collection or different?
  • In case of different collection what is the best way to join the different collection at mongo level or at application level
  • Should Call and Data details be in same collection or different.
  • Should the billed and current call and Data details be in same collection or different
  • What pattern should be used for these collections and the reason for using same

Hey @Anindya_Mohanty

My thought on your points to ponder, which ultimately depend on the access patterns of your application:

  • I would think the header and the call details should be stored in different collections. Just thinking from my usage with my cell phone provider. I rarely lookup call details. However the Header info is accessed each time on sign in.
  • I am not sure what would be best. In my case, I am using a GraphQL layer to fetch data from MongoDB in the resolver functions. Therefore to answer your question, I believe I do my ‘joins’ at the application level… if I understand your question correctly. However you could just as easily do a ‘join’ with MongoDB using $lookup with the aggregation framework. Again I am not sure what is ultimately better…
  • the call and data details I could see either in separate or the same collection. Meaning you could store all call and data data in a document per day. That way when the user wants to fetch based off a date range you would query the call/data details collections for all documents between the specific dates with the matching user _id
  • As for the billed and current details, I would store the historic data in a separate collection and keep the current usage/bill details in the header collection. Again this is just from my own thinking when it comes to what data the user will access most often. The historical data is less likely to be sought after then the current usage and billing info.
  • When you ask about the pattern to use, I am not sure what exactly you mean?