`nostr_event_store` supports three main deployment methods, each suitable for different application scenarios:
## 1. Application-integrated (e.g., `demos/base-relay`)
- Method: The event store is directly integrated into your Go application process as a library. API calls are direct, requiring no network communication.
- Advantages: Extreme performance (no network latency), simple deployment, suitable for single-machine/embedded scenarios, easy to develop and debug.
- Disadvantages: Cannot be scaled across multiple processes/machines; the event store is affected when the process crashes, making high availability difficult.
## 2. Remote deployment (e.g., `demos/remote-relay`)
- Method: The event store runs as an independent service process, communicating with the application via a gRPC remote interface.
- Advantages: Decoupling of the application and the event store; independent scaling, restarting, and monitoring; supports multiple client access; facilitates service-oriented deployment.
- Disadvantages: Network communication overhead; slightly higher deployment and maintenance complexity; slightly inferior performance compared to the built-in method in extremely low-latency scenarios.
## 3. Sharded Deployment (Under Development)
- Method: Multiple machines/processes, each running one event store instance, sharded by author pubkey hash, with a coordinator responsible for routing and aggregation.
- Advantages: Strong horizontal scalability, distributed load across single nodes, suitable for large-scale data and high-concurrency scenarios, limited impact from single shard failures.
- Disadvantages: Complex implementation and maintenance (requires coordinator, shard routing, cross-shard query aggregation), more complex consistency and recovery mechanisms, and higher initial deployment costs.
## Summary:
- Small projects/single machine: Recommended for application integration, simple and efficient.
- Requires decoupling of multiple processes/services: Recommended for remote deployment.
- For ultimate scalability and high availability: Recommended for sharded deployment, but requires more development and maintenance resources.
Project link: 
#nostr_event_store
## 2. Remote deployment (e.g., `demos/remote-relay`)
- Method: The event store runs as an independent service process, communicating with the application via a gRPC remote interface.
- Advantages: Decoupling of the application and the event store; independent scaling, restarting, and monitoring; supports multiple client access; facilitates service-oriented deployment.
- Disadvantages: Network communication overhead; slightly higher deployment and maintenance complexity; slightly inferior performance compared to the built-in method in extremely low-latency scenarios.
## 3. Sharded Deployment (Under Development)
- Method: Multiple machines/processes, each running one event store instance, sharded by author pubkey hash, with a coordinator responsible for routing and aggregation.
- Advantages: Strong horizontal scalability, distributed load across single nodes, suitable for large-scale data and high-concurrency scenarios, limited impact from single shard failures.
- Disadvantages: Complex implementation and maintenance (requires coordinator, shard routing, cross-shard query aggregation), more complex consistency and recovery mechanisms, and higher initial deployment costs.
## Summary:
- Small projects/single machine: Recommended for application integration, simple and efficient.
- Requires decoupling of multiple processes/services: Recommended for remote deployment.
- For ultimate scalability and high availability: Recommended for sharded deployment, but requires more development and maintenance resources.
Project link: GitHub
GitHub - haorendashu/nostr_event_store: A nostr event store.
A nostr event store. Contribute to haorendashu/nostr_event_store development by creating an account on GitHub.
#nostr #spam
