Skip to content

docs(readme): document per-scope service composition pattern - #17

Merged
seemenkina merged 1 commit into
mainfrom
docs/service-shape
May 14, 2026
Merged

seemenkina merged 1 commit into
mainfrom
docs/service-shape

Conversation

@seemenkina

Copy link
Copy Markdown
Collaborator

Summary

Adds a new "Service shape: one service vs. per-scope services" subsection under Core Concepts. Documents the pattern of constructing one ConsensusService per scope while sharing the storage backend across services (useful for per-conversation, per-channel, per-room consumers that want isolated event subscribers without duplicating data).

The pattern is already supported by the existing API — ConsensusStorage impls are Clone + Arc-backed, so a single storage handle can be cloned into many services, each with its own private BroadcastEventBus. This PR is documentation-only; no code changes.

Also notes that scope indexing in storage is essentially free:

  • In-memory: tens of kB per 1000 scopes.
  • Database: scope_id is a natural partition key; point lookups are identical speed, and scope-restricted queries become indexed range scans.

Test plan

  • README renders correctly (section heading sits under Core Concepts between Architecture and the responsibilities table).
  • No code touched; CI should be green.

Explain how to construct one ConsensusService per scope while sharing the
storage backend, using cloned storage handles + private BroadcastEventBus
per service. Note the negligible cost of scope-indexed storage (kB-scale
in-memory; partition key on databases).
@seemenkina
seemenkina merged commit a61c871 into main May 14, 2026
3 checks passed
@seemenkina
seemenkina deleted the docs/service-shape branch May 14, 2026 07:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant