[erlang-questions] How to design credit control application?

[Chandru]

On 7 September 2010 12:28, Tomasz Pastuch <tomasz.pastuch@REDACTED> wrote:

> Dear all,
>
> I’m quite new in erlang language, but I’m fall in love with it after
> reading Joe’s book.
> Now I’m trying to create a prototype of application just to see if erlang
> is suitable for our purpose. Let’s imagine an telco application for soft
> real-time credit control. From a stack (i.e. diameter, radius) we receive
> the information;
> -       open a session for user
> -       reserve money/debit money from "balance"
> -       close session for user
>
> The sessions can last for hours, but every 2minutes we have another
> request. Each credit control request reserves new money and debit the money
> from the previous (2m ago) reservation. Each user can have many concurrent
> sessions (>1000).  The total number of concurrent session will be max 300K.
>
> I’m thinking about designing such system in erlang. We want to have fully
> redundant system - we cannot loose customer balances.
>

We have a very similar system running here, but we handle only the DIAMETER
protocol using Erlang. We have a centralised prepay charging system, which
handles all funds. This prepay charging system operates in a master/slave
configuration. The slave will not handle any monetary operations as long as
the master is alive. The master and slave use some sort of clustering
mechanism so that they both can't serve traffic at the same time.

You are better off following a similar model. Split out the database which
handles customer balance, and have your protocol operations in separate
nodes. This way, errors in your protocol handling nodes will not affect your
system which handles customer balance.


> From the beginning I was thinking to model that situation using :
> - customer session -> spawn many erlang process at each open session, use
> mnesia replicated
>  table for storing reserved amount for each session
> - customer balances -> use mnesia replicated table
>
> The problems I have encountered:
>
> 1. Mnesia transactions cannot spread over two tables, so I can loose the
> reserve transaction (If the node fails after decreasing the value from
> balances and begin storing new reservation record). If I store the
> reservation inside the balance record, then probably I have problems with
> many (> 1000) concurrent sessions for each balance (the record will be
> simply big and the operations of updating the balance can be slower).
>

Yes you can. You can have a transaction cover any number of tables, and the
operation is guaranteed to be atomic. Either all changes are done, or none
are. There is no reason to have all reservations in the balance record.
Reservations can be in their own table, probably having a reservation id as
the primary index, and the customer id as the secondary index.


>
> 2. If we use processes for modeling user sessions then how to replicate
> those processes to the replica ? Maybe the better solution is to insert only
> a record into mnesia for each session, but how then I can process those
> sessions parallel (when the new request came)?
>

Sorry, I don't understand what you're saying here. Can you please clarify?

cheers
Chandru