I have a question about Atlassian’s database architecture to Atlassian developers. As I understand it, Atlassian keeps all tables aka domain entities (bounded contexts) in a single per tenant database. Does it make hard to develop services and not get into a trap of interconnected dependencies or hot databases? What are the pros and cons of this approach compared to splitting the data by logical parts (per context/service) and sharding each part, while hosting everything together? Is the latter more scalable and configurable in practice?
Love this write up. The detail level was enough for me to understand the concepts and the plan, but not too technical where I needed to take breaks while reading. I’m an Atlassian Application Engineer, and I appreciate the opportunity to learn in this format. Thank you.
I have a question about Atlassian’s database architecture to Atlassian developers. As I understand it, Atlassian keeps all tables aka domain entities (bounded contexts) in a single per tenant database. Does it make hard to develop services and not get into a trap of interconnected dependencies or hot databases? What are the pros and cons of this approach compared to splitting the data by logical parts (per context/service) and sharding each part, while hosting everything together? Is the latter more scalable and configurable in practice?
What if the aurora instance needs to be started again after the migration? Are they going to run into the same file count limit.
Love this write up. The detail level was enough for me to understand the concepts and the plan, but not too technical where I needed to take breaks while reading. I’m an Atlassian Application Engineer, and I appreciate the opportunity to learn in this format. Thank you.