Owners
Owners are a fundamental concept in the String Theory system, and generally represent who the money belongs to. We recommend thinking of owners like “if our system shut down today, who would we give the money back to?”
However, the actual owner modeling is extremely flexible and can be used to model various concepts. In this article we’ll cover the structure, implications of owners in the String Theory system, and common modeling patterns.
Owner Structure
Section titled “Owner Structure”Owners in String Theory are comprised of just two properties:
- ownerType : The category of owner. This is usually a general identifier like “Company”, “Employee”, or “User”
- ownerId : The specific identifier for the owner. This is usually a string that is unique within the ownerType.
Keep in mind that String Theory does not actually care about your type, your id, or what they mean to you. You have full control to model ownership in your ledger according to what makes the most sense to your business. Everything listed below are just examples we’ve seen from previous customers.
Common Examples
Section titled “Common Examples”Here are some common examples of owner types and ids:
Owner Implications
Section titled “Owner Implications”The most important thing to understand about ownership in String Theory is that moving money between owners is more difficult than changing money within the same owner.
Changing the owner of money in String Theory can only be done via the transfer operation, and is more difficult to reverse than most other operations. Additionally, while money can still be traced through String Theory transfers, it is more difficult then tracing through a standard thread relationship. Transferring between owners should be considered a financially impactful event and shouldn’t be done without strong business intent.
Common Patterns
Section titled “Common Patterns”Here are some common patterns for using owners in your system.
Keep in mind that many businesses could be modeled using more than one of these approaches. String Theory itself does not have an opinion, and they are technically interchangeable. The important thing is to choose a model that most closely fits your business processes and rules.
Beneficiary Model
Section titled “Beneficiary Model”This is the most common model we see, and the idea behind it is that the owner should be closely tied to who the money actually belongs to (this could mean legally speaking, or be something based on business rules).
Example
Section titled “Example”Let’s say you’re building an online marketplace, similar to Etsy. Your money flow is as follows:
- The customer pays for the product with their credit card
- The seller ships the product
- You pay the seller
Using the beneficiary model, you would start by making the customer the owner of the money when you first receive it. After the product ships, you would transfer the money to the seller as they are owed that money once the product ships.
When to use it
Section titled “When to use it”The beneficiary model is a good fit for most systems, and is the most common model we see. It works best, however, when there are clear business rules around how and when money moves from one beneficiary to another. If your business doesn’t have clear guidelines or controls for this the orchestrator model might fit you better.
Orchestrator Model
Section titled “Orchestrator Model”The orchestrator model is a good fit for systems where the lines between ownership in the business flow are not as clear, but you have a good idea who the process is on behalf of.
Example
Section titled “Example”Let’s say you’re building a ledger for a company that processes payroll on behalf of other companies. Your money flow is as follows:
- The company pays you for processing payroll
- You pay the employees
- You pay taxes on behalf of the company and employees
In this case, while the employees are the ultimate beneficiaries of the money, the customer company is ultimately responsible for paying its employees.
You could use the beneficiary model and have each employee be its own owner, however, since the original company responsible for the payroll has a high level of control over both the paid out wages, and the tax obligations it might make more sense to model the entire flow as being owned by the company.
When to use it
Section titled “When to use it”The orchestrator model is ideal for systems where ownership boundaries between the steps of the business process are not well defined, but ultimate responsibility for the overall flow is well defined.
Silo Model
Section titled “Silo Model”The Silo Model uses different owners to help ensure that money that should never be mixed together is kept separate.
Example
Section titled “Example”Let’s say you’re building a ledger for a university to track their assets. Universities are regularly given grants that require them to spend the money only for specific purposes. Let’s say we have grants for the following categories:
- Science
- Arts
- Athletics
Ultimately, all of this money is owned by the university, but its very important that we keep track of it separately so we can prove that it was never misused. Here we might create three separate owners like so:
- ownerType : “Grant” ownerId : “Science”
- ownerType : “Grant” ownerId : “Arts”
- ownerType : “Grant” ownerId : “Athletics”
When to use it
Section titled “When to use it”The Silo Model is a good fit for systems that need a high level of segregation between different types of money. This is most common for businesses that are government funded, have heavy compliance requirements, or transmit money on behalf of third parties.
God Model [Not Recommended]
Section titled “God Model [Not Recommended]”The god model refers to using a single owner for all money in your system.
Example
Section titled “Example”Let’s imagine you are building a ledger for a company to track their internal budgeting. All money in the system is owned by the company, and they do not hold money on behalf of any third parties.
You could use the god model here, and have a single owner for all money in the ledger.
When to use it
Section titled “When to use it”You probably shouldn’t use the god model. While it is applicable to some very specific cases (like the example above) it is almost always incorrectly used.
It’s very common, for example, to ask your company how they think they should model the money and get the initial answer of “It’s all our money”. However, when you start to dig deeper it’s usually the case that there is more granularity to the money and who it belongs to.
For example, you might find that the company has a number of different departments, and each department has its own budget. Departments shouldn’t be able to reach into each other’s budgets or see their remaining balances. Modeling the departments as individual owners would allow you to more closely model the business rules, and take advantage of more of the guard rails provided by String Theory than using the God model.
Low Level Technical Details
Section titled “Low Level Technical Details”String Theory logically shards the database by owner. This means that mutating operations cannot occur across owners. For example, you cannot withdraw money from two separate owners in the same request.
The only exception to this rule is the transfer operation, which allows moving available money from exactly one owner to exactly one other owner.