Database per Service Pattern in Microservices

Поділитися
Вставка
  • Опубліковано 14 жов 2024

КОМЕНТАРІ • 22

  • @JatinDholakia
    @JatinDholakia 2 роки тому +14

    Great video. Another disadvantage is performing joins across databases. It has to happen on network and increases latency.

    • @AsliEngineering
      @AsliEngineering  2 роки тому +4

      Oh yes. Forgot to cover that. Had that point in mind. Thanks for adding. Pinning your comment.

  • @suryansh70
    @suryansh70 2 роки тому +2

    Nice explaination + great visuals u raised the level bro

  • @simplygaurav07
    @simplygaurav07 Рік тому

    Great explanation. Thank you

  • @dhavin6322
    @dhavin6322 2 роки тому +3

    super clear explanation. Thanks

  • @abdulmoizsheikh8031
    @abdulmoizsheikh8031 2 роки тому

    Hi. Good stuff. Can you tell why cassandra was chosen for the chat service? Thanks!

    • @AsliEngineering
      @AsliEngineering  2 роки тому

      Just an example. Could have gone for any partitioned db.

    • @sakshamjain16
      @sakshamjain16 Рік тому

      IMHO Cassandra is optimized for writes. And our chat service will be write heavy because when any new message is created it will be sent to receiver over websockets or SSE or any other tech and parallelly it will be written to DB. So reads are actually not happening on chat messages in DB.

  • @jivanmainali1742
    @jivanmainali1742 2 роки тому

    So is database per service is like single collection/table for each services?

    • @AsliEngineering
      @AsliEngineering  2 роки тому

      A separate DB server per service.

    • @jivanmainali1742
      @jivanmainali1742 2 роки тому

      @@AsliEngineering yeah but let say we have 100 gb data spread over 10 collection equally so when we follow database per service for our 10 services is it 10 gb of data or we all service still has all data.

  • @waleedahmad2012
    @waleedahmad2012 Рік тому

    this was great

  • @jabedzaman
    @jabedzaman 7 місяців тому

    how do we achieve the thing about relations like my post microservice will have the post and user id and my auth service is having the user table... in short what i want to ask is in monolithic we have a single db so we can use a refrence to user table and post table to avoid making post with user id that doesnt exist... but how to do in a microservice arch??? cause we have seperate db

    • @AsliEngineering
      @AsliEngineering  7 місяців тому

      Cross node ref keys are expensive to implement and it is something that application logic needs to handle when databases do not offer it out of the box.
      Hence in microservices setup people do not implement them.

    • @jabedzaman
      @jabedzaman 7 місяців тому

      @AsliEngineering I am continuing by adding an auth guard at my api gateway will that be considered as good idea? I considered about adding something to communicate between my other service and Auth one to validate user id but I felt this may turn out to increase latency

    • @AsliEngineering
      @AsliEngineering  7 місяців тому

      @@jabedzaman yes it will shoot up the latency. Evaluate if you really need this check. What if you don't have it. Would this be a problem.

    • @jabedzaman
      @jabedzaman 7 місяців тому

      @AsliEngineering I am making an cloud suite sort of thing I just wanted to assure that my upload table doesn't have unnecessary record for user which doesn't exists... like in general it should not be but just trying to avoid in case if there turns out to be some vulnerability... just implementing an auth guard (kinda a middleware) in my api gateway so only valid authenticated user can use other service... hopefully this works out right?

    • @AsliEngineering
      @AsliEngineering  7 місяців тому

      @@jabedzaman yes. It would work.

  • @jivanmainali1742
    @jivanmainali1742 2 роки тому

    Is encryption done in db or we have to manage it seperatly?