8 ms·

We put a distributed database in the browser and made a game of it

239 points by BratishkaErik 3y ago

eatonphil 3y ago
Direct link to the game: https://sim.tigerbeetle.com/ https://sim.tigerbeetle.com/. While TigerBeetle is open-source, the game isn't yet. But that may change. :)
muhaaa 3y ago
I thought tigerbeetle distributes the db on web clients? I skimmed through the docs and cannot find how to design a web app with tigerbeetle like the game https://sim.tigerbeetle.com/ https://sim.tigerbeetle.com/
- eatonphil 3y ago
  Hey! I'm not completely sure I follow the question. But the game is built a little differently from how you'd typically run TigerBeetle in production. In production you'd run a cluster of replicas (see https://docs.tigerbeetle.com/deploy/hardware#cluster-of-replicas https://docs.tigerbeetle.com/deploy/hardware#cluster-of-repl...) and then you'd have your application connect to the cluster using one of our client libraries. The game is more a reflection of how we do simulation testing (as the post mentioned). You can find the code for that here: https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/simulator.zig https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/s....
  - muhaaa 3y ago
    I have a very interactive app with limited data use <10MB. Right now its a lots of different API calls to sync state between server and multiple clients. But if I have a distributed sync protocol (that works), I can replicate the state on each cient and server by tunneling the sync protocol to the server and back. I have reduced a lots of api complexity. My react UI just subscribes to the data changes in the synced DB. Similar concept impelmented pouchdb & couchdb but its a bit outdated.
  - cdchn 3y ago
    What did you use to make the graphics? Thats very cool.
    - eatonphil 3y ago
      They're handmade by Joy Machs! We credit him in the post. :) https://twitter.com/joymachs https://twitter.com/joymachs
      - cdchn 3y ago
        Oh the sprites are great, don't get me wrong, but I mean how the graphical game system was made.
        captainhorst 3y ago
        We use NanoVG: https://github.com/fabioarnold/nanovg-zig https://github.com/fabioarnold/nanovg-zig
        cdchn 3y ago
        Nice! Looks pretty rad. I've never used Zig but it sure looks like an interesting language. Did NanoVG help with the animation stuff like the little text that pops out of the beetles and the lines that zip between them?
        captainhorst 3y ago
        Sorry, totally missed your reply! At first we had normal text and then we switched them for hand-drawn sprites. The text animation consists of 2D transformations (translation, rotation, scale) interpolated over time. It's all animated in code. NanoVG helps by having a transformation stack like OpenGL. In Zig I can open a block like this: { vg.save(); defer vg.restore(); // undo all transformations at the end of the block vg.translate(...); vg.rotate(...); vg.scale(...); // draw sprite } // continue to draw the rest of the scene
brimstedt 3y ago
Is this something similar to couch/pouchdb?
- eatonphil 3y ago
  TigerBeetle is more domain-specific, i.e. focused on financial transactions and high-performance, high-availability. There are just two entity types in the database: accounts and transfers between accounts. More details here https://docs.tigerbeetle.com/design/data-modeling https://docs.tigerbeetle.com/design/data-modeling if you're interested!
  - jazzyjackson 3y ago
    In comparison to {C,P}ouchDB, I think the question is around offline-first availability. Can a mobile client interact with a local database without a degraded experience and expect changes to be synchronized once a connection is re-established. I would suppose in the financial transaction space this is not A Thing.
    - eatonphil 3y ago
      > In comparison to {C,P}ouchDB, I think the question is around offline-first availability. Got it, thanks! Yeah that is indeed not how TigerBeetle works. If you ever cannot connect to the cluster, you keep retry messages (idempotently) until you connect and the message succeeds.
  - jlokier 3y ago
    That sounds similar to the account state storage used in blockchains. In some of those, high performance and high space consumption are technical challenges, and the tendancy to have a lot of random keys (hashes) adds another. I wonder if TigerBeetle would be suited to those storage performance challenges, and conversely if the low-level storage optimisations in certain implementations of blockchain account history would be more broadly applicable to the financial applications targeted by TigerBeetle.
    - 3y ago
jedisct1 3y ago
This is insanely cool!
- jorangreef 3y ago
  Thanks, Frank!
Digikid13 3y ago
It's very confusing that y'all are calling this a "game". There's nothing to play, it's just a simulation to watch.
- captainhorst 3y ago
  There are tools in the upper right corner. You can pick one and use it on a beetle. ;) This introduces various faults in the simulation that the database has to recover from. Minor spoiler: there's another tiny game hidden at the end of the third level.
  - reidjs 3y ago
    That adds some interactivity, but I still wouldn't call this a game yet. Games generally have some sort of challenge you must overcome. This is more like a highly polished interactive simulation of a distributed db. Still really cool and well done.
    - deleted 3y ago
      [deleted]
  - VectorLock 3y ago
    Out of curiosity what did you use to write the graphical part of this game?
    - captainhorst 3y ago
      I used my Zig port of NanoVG: https://github.com/fabioarnold/nanovg-zig https://github.com/fabioarnold/nanovg-zig which ultimately uses WebGL for rendering in the browser.
- cstrahan 3y ago
  "Simulation" doesn't necessarily entail stimulating interactivity and a pleasing aesthetic. As of writing, I don't know if there's a better term than "game" for what this is. (Maybe we can coin a new term, like "game-lite" -- somewhat akin to what "rogue-lite" is to the "rogue" genre). See "walking simulators": https://en.wikipedia.org/wiki/What_Remains_of_Edith_Finch https://en.wikipedia.org/wiki/What_Remains_of_Edith_Finch https://en.wikipedia.org/wiki/The_Stanley_Parable https://en.wikipedia.org/wiki/The_Stanley_Parable https://en.wikipedia.org/wiki/Thirty_Flights_of_Loving https://en.wikipedia.org/wiki/Thirty_Flights_of_Loving Plenty argue that these aren't games either (usual complaints involve lack of problem(s) to resolve, and no win-lose dynamic); but, then, what are these? The closest category I can think of would be "computer-animated film", but... these are interactive, and you can navigate and look in any direction you want, which yields a very different experience than watching a film like "Toy Story".
pohl 3y ago
This is a sweet idea and a nice, game-esque implementation. It could definitely use some onboarding. There's nothing to give the "player" a hint as to what they should do. What is my goal? Am I trying to defeat the communication of the nodes, or help them? If it's the former, why did I seem to win the first level after doing nothing? I started by trying to mash some keys. Eventually I saw that there were tools in the upper-right, but it wasn't clear what to do with them. It's a bit frustrating that they disappear after you grab them if your click is too far off the target. After successfully applying one of them to one of the targets, it's not clear what one should do next. Was it a good move? Who knows, because there's no feedback.
- kristoff_it 3y ago
  Well the point is that the replication protocol is going to fix all issues no matter what, so you could say that the only winning move is to enjoy watching TigerBeetle move forward impervious of scripted nor human-inputted issues. In other words, you're going to 'win' no matter what :^)
  - pohl 3y ago
    That makes sense: it's not a game at all, but a simulation pretending to be one.
    - kristoff_it 3y ago
      never played "walking simulators" then? plenty of games don't feature traditional win-lose mechanics.
      - pohl 3y ago
        No, I hadn't even heard of that genre. They sound potentially fun, though, since at least they have an environment to explore.
        TeMPOraL 3y ago
petrosagg 3y ago
> Sure, we’re not yet injecting storage faults, but then formal proofs for protocols like Raft and Paxos assume that disks are perfect, and depend on this for correctness? After all, you can always run your database over RAID, right? Right? > If your distributed database was designed before 2018, you probably couldn’t have done much. The research didn’t exist. I'm trying to understand this part but something seems off. It seems to imply that those proofs do not apply to the real world because disks are not perfect, but neither is RAM. The hardware for both RAM and disks has an inherent error rate which can be brought down to arbitrary levels by using error correction codes (e.g ECC RAM). I'm assuming that the TigerBeetle correctness proofs are predicated on perfect RAM even though in reality there is a small probability of errors. This tells me that there is an error rate which they consider negligible. If that's the case what is the difference between: * TigerBeetle's storage approach * Paxos or Raft with enough error correction on disk writes that the probability of errors equals that of ECC RAM which is considered negligible I've probably made a logical error in my reasoning but I can't see it. Can someone enlighten me?
- chubot 3y ago
  Not an expert in this area, but I think disks have correlated failure modes whereas CPUs and memory generally don't. Especially spinning platter disks, not sure about SSDs. The difference in failure rates could be orders of magnitude ... Memory will have random bit flips but I think they are pretty randomly distributed (or maybe catastrophic if there is some cosmic event) But disks will have non-random manufacturing issues. I'd be interested in more info too, but my impression is that the data on these issues is pretty thin. Foundation DB mentioned it ~10 years ago and Google has published data >10 years ago, but hardware has changed a lot since then Software redundancy will take care of non-correlated failures, but it fails precisely when there are correlated ones
  - planckscnst 3y ago
    I work on a large distributed database system. SSDs absolutely have correlated failures. Also CMOS batteries. Also CPU and memory (think a manufacturing defect or a storage climate issue on specific batches that made it through QA). Pretty much nothing is 100% guaranteed to have no correlated failures. It comes down to probabilities. You can add flexibility, variation, vendor/sourcing diversity to reduce risks.
cdchn 3y ago
This is pretty cool from a database perspective but I'm really interested in what they used to write this 'game.'
- eatonphil 3y ago
  It's covered a little bit in the Evolution section (add #evolution to the URL and hit enter). If that doesn't answer everything (it's not a long section, granted) Fabio (captainhorst) is on HN answering questions in this thread already so feel free to ask!
  - cdchn 3y ago
    I went to https://sim.tigerbeetle.com/#evolution https://sim.tigerbeetle.com/#evolution but nothing happened.
    - eatonphil 3y ago
      Of the blog post, sorry, not sim.tigerbeetle.com.
moralestapia 3y ago
Nice work @eatonphil and TB team. Thanks for sharing. I'm eagerly awaiting the production ready (or an RC or something) of TB, I've tried it and it truly excels in its domain. I have a few clients that could make good use of it but I have to hold my horses a little bit.
- jorangreef 3y ago
  Thanks, Alex! Awesome to hear that. SimTigerBeetle has been a skunkworks project, on the side, the past 12 months. We're looking forward to sharing the production release of TigerBeetle with you soon when it's ready.
schmichael 3y ago
This is incredible! I am curious about this paragraph though: > You’re going to see view changes when the primary crashes or is partitioned, and VSR’s telltale round robin rotation of the new primary among replicas, until a new primary is established. This is in contrast to Raft, which elects a primary at random, but then suffers from the risk of (or increased latency to mitigate) dueling leaders. It seems like regardless of primary/leader selection mechanism used (deterministic/roundrobin vs voting), you still need a quorum of nodes to agree (and for the minority side to know they can't proceed). Surely in a round robin selection mechanism some sort of vote or liveness check must be performed before it is safe for the #2 node to promote itself to #1/primary? Otherwise if the link between #2 and #1/primary is partitioned, #2 could unilaterally assume it was the primary/leader, even if the rest of the nodes could still communicate with #1 (the original primary). I don't understand how round robin solves the agreement aspect that leader election does. The simulation seems to only partition nodes and not links so I'm not sure it exercises asymmetric connectivity between members. Although it does mention flaky links, so perhaps they do cover this case. Edit: I have been informed there is still a vote. :)
- jorangreef 3y ago
  Thanks, great to hear you enjoyed it! The round robin "view change" in VSR is still consensus, and uses quorums to do fault isolation of the old primary, and to preserve the intersection property, to ensure that the committed log survives into the new view. What's cool about VSR's consensus though, is that the dice is also preloaded, ahead of time, so that there's more information baked into the protocol than with Raft or MultiPaxos, which means that you can neatly sidestep their dueling leader problem, or the latency padding that is often added to mitigate it. You can read more about VSR's intuitive view change consensus here: http://pmg.csail.mit.edu/papers/vr-revisited.pdf http://pmg.csail.mit.edu/papers/vr-revisited.pdf The round robin view chance can also make VSR (slightly) more resilient to weird network faults, like you describe. For example, variants of VSR using stable storage as hinted at by the '12 paper, are in fact able to survive most of the OmniPaxos liveness scenarios (we submitted some errata to the paper's authors for this). We haven't yet explored visualizing asymmetric connectivity in SimTigerBeetle (we tried to start with the big things!), however we recently wrote about how we test for this in our VOPR simulator here: https://tigerbeetle.com/blog/2023-07-06-simulation-testing-for-liveness/ https://tigerbeetle.com/blog/2023-07-06-simulation-testing-f...
charbuff 3y ago
This is a really cool sales prop
nlavezzo 3y ago
This is awesome!
- jorangreef 3y ago
  Thanks, Nick! All credit to FoundationDB.
zelda-mazzy 3y ago
This is so cool!

239 points by BratishkaErik 3y ago

Direct link to the game: https://sim.tigerbeetle.com/ https://sim.tigerbeetle.com/. While TigerBeetle is open-source, the game isn't yet. But that may change. :)

muhaaa 3y ago

I thought tigerbeetle distributes the db on web clients? I skimmed through the docs and cannot find how to design a web app with tigerbeetle like the game https://sim.tigerbeetle.com/ https://sim.tigerbeetle.com/

eatonphil 3y ago
Hey! I'm not completely sure I follow the question. But the game is built a little differently from how you'd typically run TigerBeetle in production. In production you'd run a cluster of replicas (see https://docs.tigerbeetle.com/deploy/hardware#cluster-of-replicas https://docs.tigerbeetle.com/deploy/hardware#cluster-of-repl...) and then you'd have your application connect to the cluster using one of our client libraries. The game is more a reflection of how we do simulation testing (as the post mentioned). You can find the code for that here: https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/simulator.zig https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/s....
- muhaaa 3y ago
  I have a very interactive app with limited data use <10MB. Right now its a lots of different API calls to sync state between server and multiple clients. But if I have a distributed sync protocol (that works), I can replicate the state on each cient and server by tunneling the sync protocol to the server and back. I have reduced a lots of api complexity. My react UI just subscribes to the data changes in the synced DB. Similar concept impelmented pouchdb & couchdb but its a bit outdated.
- cdchn 3y ago
  What did you use to make the graphics? Thats very cool.
  - eatonphil 3y ago
    They're handmade by Joy Machs! We credit him in the post. :) https://twitter.com/joymachs https://twitter.com/joymachs
    - cdchn 3y ago
      Oh the sprites are great, don't get me wrong, but I mean how the graphical game system was made.
      - captainhorst 3y ago
        We use NanoVG: https://github.com/fabioarnold/nanovg-zig https://github.com/fabioarnold/nanovg-zig
        cdchn 3y ago
        Nice! Looks pretty rad. I've never used Zig but it sure looks like an interesting language. Did NanoVG help with the animation stuff like the little text that pops out of the beetles and the lines that zip between them?
        captainhorst 3y ago
        Sorry, totally missed your reply! At first we had normal text and then we switched them for hand-drawn sprites. The text animation consists of 2D transformations (translation, rotation, scale) interpolated over time. It's all animated in code. NanoVG helps by having a transformation stack like OpenGL. In Zig I can open a block like this: { vg.save(); defer vg.restore(); // undo all transformations at the end of the block vg.translate(...); vg.rotate(...); vg.scale(...); // draw sprite } // continue to draw the rest of the scene

brimstedt 3y ago

Is this something similar to couch/pouchdb?

eatonphil 3y ago
TigerBeetle is more domain-specific, i.e. focused on financial transactions and high-performance, high-availability. There are just two entity types in the database: accounts and transfers between accounts. More details here https://docs.tigerbeetle.com/design/data-modeling https://docs.tigerbeetle.com/design/data-modeling if you're interested!
- jazzyjackson 3y ago
  In comparison to {C,P}ouchDB, I think the question is around offline-first availability. Can a mobile client interact with a local database without a degraded experience and expect changes to be synchronized once a connection is re-established. I would suppose in the financial transaction space this is not A Thing.
  - eatonphil 3y ago
    > In comparison to {C,P}ouchDB, I think the question is around offline-first availability. Got it, thanks! Yeah that is indeed not how TigerBeetle works. If you ever cannot connect to the cluster, you keep retry messages (idempotently) until you connect and the message succeeds.
- jlokier 3y ago
  That sounds similar to the account state storage used in blockchains. In some of those, high performance and high space consumption are technical challenges, and the tendancy to have a lot of random keys (hashes) adds another. I wonder if TigerBeetle would be suited to those storage performance challenges, and conversely if the low-level storage optimisations in certain implementations of blockchain account history would be more broadly applicable to the financial applications targeted by TigerBeetle.
  - 3y ago

jedisct1 3y ago

This is insanely cool!

jorangreef 3y ago
Thanks, Frank!

Digikid13 3y ago

It's very confusing that y'all are calling this a "game". There's nothing to play, it's just a simulation to watch.

captainhorst 3y ago
There are tools in the upper right corner. You can pick one and use it on a beetle. ;) This introduces various faults in the simulation that the database has to recover from. Minor spoiler: there's another tiny game hidden at the end of the third level.
- reidjs 3y ago
  That adds some interactivity, but I still wouldn't call this a game yet. Games generally have some sort of challenge you must overcome. This is more like a highly polished interactive simulation of a distributed db. Still really cool and well done.
  - deleted 3y ago
    [deleted]
- VectorLock 3y ago
  Out of curiosity what did you use to write the graphical part of this game?
  - captainhorst 3y ago
    I used my Zig port of NanoVG: https://github.com/fabioarnold/nanovg-zig https://github.com/fabioarnold/nanovg-zig which ultimately uses WebGL for rendering in the browser.
cstrahan 3y ago
"Simulation" doesn't necessarily entail stimulating interactivity and a pleasing aesthetic. As of writing, I don't know if there's a better term than "game" for what this is. (Maybe we can coin a new term, like "game-lite" -- somewhat akin to what "rogue-lite" is to the "rogue" genre). See "walking simulators": https://en.wikipedia.org/wiki/What_Remains_of_Edith_Finch https://en.wikipedia.org/wiki/What_Remains_of_Edith_Finch https://en.wikipedia.org/wiki/The_Stanley_Parable https://en.wikipedia.org/wiki/The_Stanley_Parable https://en.wikipedia.org/wiki/Thirty_Flights_of_Loving https://en.wikipedia.org/wiki/Thirty_Flights_of_Loving Plenty argue that these aren't games either (usual complaints involve lack of problem(s) to resolve, and no win-lose dynamic); but, then, what are these? The closest category I can think of would be "computer-animated film", but... these are interactive, and you can navigate and look in any direction you want, which yields a very different experience than watching a film like "Toy Story".

pohl 3y ago

This is a sweet idea and a nice, game-esque implementation. It could definitely use some onboarding. There's nothing to give the "player" a hint as to what they should do. What is my goal? Am I trying to defeat the communication of the nodes, or help them? If it's the former, why did I seem to win the first level after doing nothing? I started by trying to mash some keys. Eventually I saw that there were tools in the upper-right, but it wasn't clear what to do with them. It's a bit frustrating that they disappear after you grab them if your click is too far off the target. After successfully applying one of them to one of the targets, it's not clear what one should do next. Was it a good move? Who knows, because there's no feedback.

kristoff_it 3y ago
Well the point is that the replication protocol is going to fix all issues no matter what, so you could say that the only winning move is to enjoy watching TigerBeetle move forward impervious of scripted nor human-inputted issues. In other words, you're going to 'win' no matter what :^)
- pohl 3y ago
  That makes sense: it's not a game at all, but a simulation pretending to be one.
  - kristoff_it 3y ago
    never played "walking simulators" then? plenty of games don't feature traditional win-lose mechanics.
    - pohl 3y ago
      No, I hadn't even heard of that genre. They sound potentially fun, though, since at least they have an environment to explore.
      - TeMPOraL 3y ago

petrosagg 3y ago

> Sure, we’re not yet injecting storage faults, but then formal proofs for protocols like Raft and Paxos assume that disks are perfect, and depend on this for correctness? After all, you can always run your database over RAID, right? Right? > If your distributed database was designed before 2018, you probably couldn’t have done much. The research didn’t exist. I'm trying to understand this part but something seems off. It seems to imply that those proofs do not apply to the real world because disks are not perfect, but neither is RAM. The hardware for both RAM and disks has an inherent error rate which can be brought down to arbitrary levels by using error correction codes (e.g ECC RAM). I'm assuming that the TigerBeetle correctness proofs are predicated on perfect RAM even though in reality there is a small probability of errors. This tells me that there is an error rate which they consider negligible. If that's the case what is the difference between: * TigerBeetle's storage approach * Paxos or Raft with enough error correction on disk writes that the probability of errors equals that of ECC RAM which is considered negligible I've probably made a logical error in my reasoning but I can't see it. Can someone enlighten me?

chubot 3y ago
Not an expert in this area, but I think disks have correlated failure modes whereas CPUs and memory generally don't. Especially spinning platter disks, not sure about SSDs. The difference in failure rates could be orders of magnitude ... Memory will have random bit flips but I think they are pretty randomly distributed (or maybe catastrophic if there is some cosmic event) But disks will have non-random manufacturing issues. I'd be interested in more info too, but my impression is that the data on these issues is pretty thin. Foundation DB mentioned it ~10 years ago and Google has published data >10 years ago, but hardware has changed a lot since then Software redundancy will take care of non-correlated failures, but it fails precisely when there are correlated ones
- planckscnst 3y ago
  I work on a large distributed database system. SSDs absolutely have correlated failures. Also CMOS batteries. Also CPU and memory (think a manufacturing defect or a storage climate issue on specific batches that made it through QA). Pretty much nothing is 100% guaranteed to have no correlated failures. It comes down to probabilities. You can add flexibility, variation, vendor/sourcing diversity to reduce risks.

cdchn 3y ago

This is pretty cool from a database perspective but I'm really interested in what they used to write this 'game.'

eatonphil 3y ago
It's covered a little bit in the Evolution section (add #evolution to the URL and hit enter). If that doesn't answer everything (it's not a long section, granted) Fabio (captainhorst) is on HN answering questions in this thread already so feel free to ask!
- cdchn 3y ago
  I went to https://sim.tigerbeetle.com/#evolution https://sim.tigerbeetle.com/#evolution but nothing happened.
  - eatonphil 3y ago
    Of the blog post, sorry, not sim.tigerbeetle.com.

moralestapia 3y ago

Nice work @eatonphil and TB team. Thanks for sharing. I'm eagerly awaiting the production ready (or an RC or something) of TB, I've tried it and it truly excels in its domain. I have a few clients that could make good use of it but I have to hold my horses a little bit.

jorangreef 3y ago
Thanks, Alex! Awesome to hear that. SimTigerBeetle has been a skunkworks project, on the side, the past 12 months. We're looking forward to sharing the production release of TigerBeetle with you soon when it's ready.

schmichael 3y ago

This is incredible! I am curious about this paragraph though: > You’re going to see view changes when the primary crashes or is partitioned, and VSR’s telltale round robin rotation of the new primary among replicas, until a new primary is established. This is in contrast to Raft, which elects a primary at random, but then suffers from the risk of (or increased latency to mitigate) dueling leaders. It seems like regardless of primary/leader selection mechanism used (deterministic/roundrobin vs voting), you still need a quorum of nodes to agree (and for the minority side to know they can't proceed). Surely in a round robin selection mechanism some sort of vote or liveness check must be performed before it is safe for the #2 node to promote itself to #1/primary? Otherwise if the link between #2 and #1/primary is partitioned, #2 could unilaterally assume it was the primary/leader, even if the rest of the nodes could still communicate with #1 (the original primary). I don't understand how round robin solves the agreement aspect that leader election does. The simulation seems to only partition nodes and not links so I'm not sure it exercises asymmetric connectivity between members. Although it does mention flaky links, so perhaps they do cover this case. Edit: I have been informed there is still a vote. :)

jorangreef 3y ago
Thanks, great to hear you enjoyed it! The round robin "view change" in VSR is still consensus, and uses quorums to do fault isolation of the old primary, and to preserve the intersection property, to ensure that the committed log survives into the new view. What's cool about VSR's consensus though, is that the dice is also preloaded, ahead of time, so that there's more information baked into the protocol than with Raft or MultiPaxos, which means that you can neatly sidestep their dueling leader problem, or the latency padding that is often added to mitigate it. You can read more about VSR's intuitive view change consensus here: http://pmg.csail.mit.edu/papers/vr-revisited.pdf http://pmg.csail.mit.edu/papers/vr-revisited.pdf The round robin view chance can also make VSR (slightly) more resilient to weird network faults, like you describe. For example, variants of VSR using stable storage as hinted at by the '12 paper, are in fact able to survive most of the OmniPaxos liveness scenarios (we submitted some errata to the paper's authors for this). We haven't yet explored visualizing asymmetric connectivity in SimTigerBeetle (we tried to start with the big things!), however we recently wrote about how we test for this in our VOPR simulator here: https://tigerbeetle.com/blog/2023-07-06-simulation-testing-for-liveness/ https://tigerbeetle.com/blog/2023-07-06-simulation-testing-f...

charbuff 3y ago

This is a really cool sales prop

nlavezzo 3y ago

This is awesome!

jorangreef 3y ago
Thanks, Nick! All credit to FoundationDB.

zelda-mazzy 3y ago

This is so cool!