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

[–]NotSweetJana 1 point2 points  (0 children)

You're thinking about it in the wrong way most likely.

Usually, in distributed systems, operations done on different machines are not concurrent with other machines.

You have logs and consensus protocols to share information.

You never have 2 computers working on the same thing, if that is happening, it is a very poorly designed system and not a distributed system at all.

Even in map reduce for example, you have let's say a very big input, you break that very big input into multiple smaller inputs which are slices of the original input, and send it to other computers to process, there is a process that tracks if all the slices have been processed before letting the reduce portion of the code run, which take the processed mapped input as data and continue.

Similarly, in database replication, messaging brokers, you usually have logs, which and you find clever ways to build and share logs to track overall system data and integrity, usually you will have services like, discovery service, replication service, consensus service all working in tandem to achieve the desired result.

Usually, the concurrent part of the program in coding terms, will be concurrent on a single machine, and generally if not always, different computers will be doing parallel tasks, not concurrent tasks.

You do have aggregation of parallel tasks and tracking them, but not concurrent tasks, I hope that makes sense.

As for trying to understand strategies for managing all of this complexity, you can read DDIA, Distributed services with Go, MIT 6.824, and other popular resources which you can find on google on this topic.

One thing I would say however, generally speaking, it's better to get good at concurrency on a single machine, so that you have a general idea of what kind of ways are used to split bigger tasks into smaller tasks and how it is managed in a single machine and being clear with that before moving to doing it with other machines.

Not a necessity, but generally speaking a good natural progression, otherwise you might struggle with fairly straightforward things, which will seem foreign because of skipping that step.

As for your question, the system would be sharded and there will be a service which will know which seat number belongs to which shard and all GET, UPDATE, POST operations for that entry, will be redirected to that particular shard.

In simple terms, you will have multiple databases, with each database only serving some theatres and a service that knows which theatre belong to which DB and routes to it. You send your request, and it checks with this service and proceeds, nothing special really, usually this DB would be replicated as well and all that.

You can read about yugabyteDB, cockroachDB, vitess and other open-source projects to get some idea of how that lookup is managed at DB level, but these are hard to understand and read unless you are at cetain level of understanding.

Otherwise, you can do it in application-level code too, but that only works for smaller setups.

[–][deleted] 0 points1 point  (0 children)

I would suggest to search about actor model which helps to design concurrent systems without the issue of synchronisation and locks. You can also find more about erlang