update README.md

Author: srinathln7

DESIGN.md

@@ -1,6 +1,7 @@
 # VC-Ethereum Data Service Architecture
 
-The pivotal decision in our architecture aimed at storing information for the most recent 50 blocks centers around our database choice. Given the project's scope and requirements detailed [here](https://github.com/srinathln7/ethereum-data-service/blob/main/docs/CHALLENGE.md), Redis was selected as our local store. The rationale behind this decision is thoroughly outlined [here](https://github.com/srinathln7/ethereum-data-service/blob/main/docs/REDIS.md).
+The pivotal decision in our architecture aimed at storing information for the most recent 50 blocks centers around our database choice. Given the project's scope and requirements detailed [here](https://github.com/srinathln7/ethereum-data-service/blob/main/docs/CHALLENGE.md), Redis was selected as our local store. The rationale behind this decision is thoroughly outlined [here](https://github.com/srinathln7/ethereum-data-service/blob/main/docs/REDIS.md). This design strives to efficiently combine real-time and historical Ethereum data processing (most recent 50 blocks at the time of launching the application), leveraging Redis for both message brokering and data storage. The API Service ensures that clients have quick and reliable access to the latest blockchain data.
+
 
 ```mermaid
 graph TD
@@ -16,7 +17,7 @@ graph TD
 
     subgraph VC-ETH-Data-Service
         direction TB
-        ethereumNode["Ethereum Node<br/>(WebSocket & HTTPS RPC)"]:::ethereumNodeStyle
+        ethereumNode["Ethereum Node<br/>(HTTPS RPC & WebSocket)"]:::ethereumNodeStyle
         blockNotification["Block<br/>Notification"]:::blockNotificationStyle
         bootstrapper["Bootstrapper"]:::bootstrapperStyle
         redisChannel(["Redis Channel"]):::redisChannelStyle
@@ -99,8 +100,6 @@ The VC-Ethereum Data Service architecture streamlines the retrieval, processing,
 
 In the design, we start the **Bootstrapper** and **BlockNotification** services simultaneously. The Bootstrapper fetches the latest block height (`h`), retrieves data from `h-50` to `h`, and exits gracefully. This process takes about 5 minutes, so we set the TTL for block info in Redis to 650 seconds (50 * 13 seconds, the average ETH block time). Concurrently, the block notifier publishes real-time block info to Redis with the same TTL. Initially, our datastore holds more than 50 blocks, but it eventually stabilizes at 50 blocks. Despite the initial load, Redis memory usage remains well within its capabilities.
 
-#### Data Formatter
-
+### Data Formatter
 The `Data Formatter` module integrates as a component rather than a standalone service, ensuring uniform data formatting across Bootstrapper and Block Subscriber. This approach maximizes code reuse and data integrity within the VC-Ethereum Data Service architecture.
 
-Overall, this design strives to efficiently combine real-time and historical Ethereum data processing, leveraging Redis for both message brokering and data storage. The API Service ensures that clients have quick and reliable access to the latest blockchain data.

README.md

@@ -108,7 +108,7 @@ This validates that Redis is an optimal choice for our current project requireme
 
 In our current architecture, each service operates with a single instance, making each service vulnerable to being a single point of failure. This becomes particularly critical because if Redis experiences downtime, it impacts the entire application. To address this, we can implement well-known strategies such as deploying Redis in a high-availability configuration using Redis Sentinel or Redis Cluster. Additionally, adopting container orchestration platforms like Kubernetes can enable automatic scaling and resilience by managing multiple instances of each service. Implementing load balancing across these instances can further enhance availability and fault tolerance and incorporating monitoring and alerting mechanisms helps in promptly identifying and mitigating issues before they impact the entire system. These approaches collectively aim to enhance the reliability and availability of our application architecture.
 
-As part of future improvements, we consider the following tasks:
+As part of future improvements, we can consider the following tasks:
 
 ### Easy-to-Query APIs
 
@@ -124,17 +124,6 @@ To secure the API, I would implement the following measures:
 
 - **HTTPS:** Use HTTPS to encrypt communication between clients and the API.
 
-### Performance Optimization
-
-To improve the performance of the service, I would consider the following optimizations:
-
-- **Load Balancing:** Use a load balancer to distribute incoming requests across multiple instances of the service.
-  
-- **Horizontal Scaling:** Scale the service horizontally by adding more instances behind the load balancer.
-
-
-### Design to store the entire ETH mainnet data
- 
 
 ## References
 

docs/REDIS.md

@@ -9,7 +9,7 @@ Based on recent Ethereum block sizes from [Etherscan](https://etherscan.io/chart
 - **Block Data**: Approximately 200 KB per block.
 - **Transaction Data**:
   - Average of 200 transactions per block.
-  - Each transaction key (Hash: 32 bytes) and actual tx data (750 bytes) contribute to about 156 KB per block.
+  - Each transaction key (Hash: 32 bytes) and actual Tx data (750 bytes) contribute to about 156 KB per block.
 - **Event Data**:
   - Assuming an average of 2 events per transaction, contributing approximately 312 KB per block.
 
@@ -34,7 +34,7 @@ With additional overhead for indexing and metadata, our total storage requiremen
 
 ### Concurrent Requests
 
-- **Concurrency Support**: Redis efficiently handles multiple concurrent client requests thereby enhancing application responsiveness.
+- **Concurrency Support**: Redis efficiently handles multiple concurrent client requests thereby enhancing application responsiveness. At the start of our application, both the **Bootstrapper** and **BlockNotification** service starts write concurrently to Redis.
 
 ### Performance Monitoring
 

internal/model/model.go

@@ -16,7 +16,8 @@ type Block struct {
 
 // Data represents storage data in Redis DB for Ethereum-related information.
 // It includes Ethereum block data, transaction hashes mapped to transactions,
-// and event data mapped to specific event addresses.
+// and event data mapped to specific event addresses. Block data byitself
+// contains Tx hashes but as per the challenge description, we store it explicitly here
 type Data struct {
 	Block             Block                         `json:"block"`              // Block holds Ethereum block information.
 	TransactionHashes map[string]*types.Transaction `json:"transaction_hashes"` // TransactionHashes maps transaction hashes to their corresponding transactions.