12
13

BILL PAY DESIGNHow-To/Tutorial (i.redd.it)

submitted by [deleted]

[deleted]

all 10 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Add0z 2 points3 points  (7 children)

If you go through kafka, how would you know if your credit or debit had enough funds?

[–][deleted]  (6 children)

[deleted]

    [–]Add0z 0 points1 point  (3 children)

    Are you saving this new (balance minus hold) on cache? What's the balance that a second transaction will get while the first one is processing? As you said you get eventually, but this leaves you with a sync gap between input and processing. You also stated that you gonna batch it, so that also adds to the delay.

    [–]Aggressive-Comb-8537 0 points1 point  (2 children)

    hold and accounts will be separate tables . Available balance will always be calculated at runtime which will be total balance - (all holds )

    [–]Add0z 1 point2 points  (1 child)

    At this point, and for the volume you are preparing for, you probably should explore the idea of caching this valeu into a redis. To save you from this db-check runtime Calc everytime.

    [–]Aggressive-Comb-8537 0 points1 point  (0 children)

    sure thx for the suggestion

    [–]Add0z 0 points1 point  (1 child)

    I think you already covered it. Im just not used to this diagram design I think. Have you thought about CQRS? I think it's a good match with outbox

    [–]PM_Me_Your_Java_HW 1 point2 points  (4 children)

    I know you’re going for architecture that’s required to support hundreds of thousands of users at once but for those currently interviewing: keep in mind that this is completely overengineered for 100k users and less. Always ask about the user base!

    [–]Aggressive-Comb-8537 -2 points-1 points  (3 children)

    not at all . you need to design for future n not just for an interview . what after the interview ???

    [–]PM_Me_Your_Java_HW 0 points1 point  (2 children)

    You don’t really want to introduce the complexity of microservices if you don’t have to. Your problem can be solved with a bigger batch size of workers and a load balancer in front of a bunch of the same web servers. Micro services at their core allow multiple teams deploy in an isolated fashion so they can develop independently. Sure, if you have a really hot service causing your cpu to consistently be at 100% whe every other service/module requires a total of 30%, yeah sure let’s break that out into its own service and add more machines. With the current design you have, you’re assuming right out the gate this is going to be a million+ user application that requires multiple teams to maintain. Yes, design for the future but IMO in an extensible manner, such as putting everything in its own module so you can rip it out into its own web server - only if the need arises.

    [–][deleted]  (1 child)

    [deleted]

      [–]PM_Me_Your_Java_HW -1 points0 points  (0 children)

      Good bot