You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I see in the codebase that the message bus is initialized once at bootstrap(). It carries a single (probably global) instance of the unit of work.
Isnt this not dangerous?
If two commands are simultaneously processing, they would be inside the same message bus and use the same unit of work. While the first command tries to commit, if the second command has added some entities to be committed, wouldn't they not be prematurely committed?
Same argument can be given if one command tries to rollback while other commands try to commit (simultaneously).
Since the context manager freshly initializes the sqlalchemy session, the session entity is still different whenever
with uow:
<bla bla>
is done. However the old session has lost the reference and could be garbage cleaned?
I am not familiar with the inner workings of sqlalchemy, but it looks like the more correct pattern would be to have a message handler per route or command.
One could do this by combining the bootstrap with the fastapi.param.Depends , for example
I bring this up because I tried to once promote the unit of work to a singleton (which is similar to the behaviour in this codebase) and it was not at all happy. There were inconsistencies in the repository, which disappeared once I removed the singleton behaviour.
I'm no expert, just someone who likes the book, but my takeaway is that the examples provided by the authors are for simple synchronous systems. The messagebus in the book only has the uow instance as a simple way to collect events. The authors say themselves that this is a convenient option and not what they do in production iirc.
Your fastapi Depends implementation seems perfectly fine to solve your problem. You could also create an EventCollector so the MessageBus doesn't directly know about the uow. Or maybe make the uow a factory instead of an instance. This would make bootstrap lighter weight which helps if you're doing per-request isolation.
Reacted by Vignesh Venkatasubramanian Vaidyanathan
I'm no expert, just someone who likes the book, but my takeaway is that the examples provided by the authors are for simple synchronous systems. The messagebus in the book only has the uow instance as a simple way to collect events. The authors say themselves that this is a convenient option and not what they do in production iirc.
Your fastapi Depends implementation seems perfectly fine to solve your problem. You could also create an EventCollector so the MessageBus doesn't directly know about the uow. Or maybe make the uow a factory instead of an instance. This would make bootstrap lighter weight which helps if you're doing per-request isolation.
Activity
[-]Shared message bus multiple commands?[/-][+]Shared message bus for multiple commands?[/+]wonyoung-jang commentedon Jun 11, 2026
I'm no expert, just someone who likes the book, but my takeaway is that the examples provided by the authors are for simple synchronous systems. The messagebus in the book only has the uow instance as a simple way to collect events. The authors say themselves that this is a convenient option and not what they do in production iirc.
Your fastapi Depends implementation seems perfectly fine to solve your problem. You could also create an EventCollector so the MessageBus doesn't directly know about the uow. Or maybe make the uow a factory instead of an instance. This would make bootstrap lighter weight which helps if you're doing per-request isolation.
VigneshVSV commentedon Jun 14, 2026
Agree. Thank you.