Node.js Developer Needed to Fix Slow Website Caused by Hive RPC Retry Storm
Presupuesto: $5.0
FIXED /
⭐ 4.95 (46)
Philippines
node.js
Cualificaciones preferidas
- Tipo de talento: Independiente
- Experiencia: Nivel inicial
- Inglés: Fluido
- Job Success: 80%+
- Se prefiere Rising Talent
- Ganancias mín.: $100+
We are looking for an experienced Node.js developer to fix a production performance issue on Honouree.com.
The website runs in Docker on an AWS EC2 t3.medium instance behind Nginx. The current application becomes very slow because the Node.js container repeatedly switches among failing Hive RPC endpoints after network timeouts, refused connections, and DNS errors.
The container has reached approximately 180% CPU usage, while available memory and disk space remain acceptable. The main goal of this job is to stop the uncontrolled RPC retry behavior and restore normal website loading speed.
This job is not simply about upgrading the EC2 instance. The underlying retry, failover, timeout, and fault-isolation logic must be corrected.
Main objective
Make Honouree.com load normally even when some or all Hive RPC endpoints are slow or unavailable.
The website must continue loading:
• Navigation
• Page layout
• Login and authentication
• Locally stored content
• Database-backed content
• Non-Hive services
• Other unrelated website features
Only the specific components that require successful Hive RPC data may show a temporary unavailable message.
A Hive RPC failure must not cause the entire website to hang, time out, show a blank page, or return a global server error.
Approved Hive RPC endpoint pool
The implementation must use this centrally managed list:
https://api.hive.blog
https://api.openhive.network
https://anyx.io
https://rpc.ausbit.dev
https://rpc.mahdiyari.info
https://api.hive.blue
https://techcoderx.com
https://hive.roelandp.nl
https://hived.emre.sh
https://api.deathwing.me
https://api.c0ff33a.uk
https://hive-api.arcange.eu
https://hive-api.3speak.tv
https://hiveapi.actifit.io
https://rpc.ecency.com
The endpoints must not be retried continuously or treated as permanently healthy.
Scope of work
1. Identify the current code responsible for Hive RPC retries, failover, and endpoint switching.
2. Stop infinite or rapid endpoint rotation.
3. Limit each Hive operation to a maximum of 3 attempts, a maximum of 3 different RPC endpoints, and a maximum total operation time of approximately 15 seconds.
4. Add request timeout and actual request cancellation using AbortController or an equivalent method.
5. Add exponential backoff with jitter between retries.
6. Add a basic circuit breaker for each endpoint.
7. Temporarily remove an endpoint from rotation after repeated failures.
8. Prevent many simultaneous website requests from starting separate RPC failover loops.
9. Centralize endpoint health status so all requests share the same state.
10. Ensure non-Hive parts of the website render without waiting for Hive RPC calls.
11. Show a localized fallback message only in the affected Hive-dependent component.
12. Keep the approved endpoint list in one configuration file or environment variable.
13. Rebuild and redeploy the Docker application properly from source.
14. Verify that the fix survives a container restart.
15. Provide rollback instructions.
Required behavior
• If a Hive feed request fails, the rest of the page must still load.
• If an account balance cannot be retrieved, only the balance section should show an unavailable message.
• If several RPC endpoints fail, the application should stop retrying after the configured limit.
• If all RPC endpoints fail, the website should still return a usable page.
• Failed endpoints should enter cooldown instead of being selected again immediately.
• The application should not continuously print repeated “Switched Hive RPC” messages.
• Container CPU usage should return to a reasonable level.
Suggested message for affected components:
Live Hive data is temporarily unavailable. Other Honouree features remain accessible.
Deliverables
• Root-cause analysis
• Updated source code
• Centralized RPC endpoint configuration
• Bounded retry logic
• Request timeout and cancellation
• Exponential backoff with jitter
• Basic per-endpoint circuit breaker
• Shared endpoint health state
• Component-level fallback handling
• Rebuilt Docker image
• Production deployment
• Before-and-after CPU measurements
• Before-and-after homepage response-time measurements
• Testing evidence
• Deployment instructions
• Rollback instructions
Acceptance criteria
1. Honouree.com loads even when multiple RPC endpoints are unavailable.
2. The homepage does not wait for a complete endpoint rotation before appearing.
3. Navigation and non-Hive features remain functional.
4. Only Hive-dependent components show temporary error states.
5. No single operation contacts more than 3 RPC endpoints.
6. Failed endpoints enter cooldown.
7. Continuous RPC-switching log spam stops.
8. Container CPU no longer remains near 180% during normal operation.
9. CPU usage decreases after RPC failures instead of remaining saturated.
10. The website still loads when at least 5 RPC endpoints are intentionally blocked.
11. The application does not return a blank page or global 500, 502, or 503 error solely because Hive RPC is unavailable.
12. The deployed fix survives a Docker container restart.
13. The approved 15-endpoint list is centrally configured.
14. The developer provides before-and-after performance results.
Required experience
• Node.js
• Asynchronous JavaScript
• HTTP request cancellation
• Retry and backoff strategies
• Circuit breaker patterns
• Concurrency control
• Docker
• Nginx
• AWS EC2
• Performance profiling
• External API fault tolerance
• JSON-RPC
Experience with Hive blockchain RPC endpoints is preferred.
Application instructions
1. A brief explanation of how you would stop many simultaneous requests from starting separate RPC failover loops.
2. An example of a similar retry, timeout, or circuit-breaker system you have implemented.
3. Your proposed method for keeping non-Hive parts of the website available during a complete RPC outage.
4. Your estimated timeline.
5. Your fixed-price proposal.
6. Confirmation that you can work with an existing Dockerized Node.js application on AWS EC2.
7. Confirmation that you will test the changes safely before production deployment.
Abrir en Upwork
AI proposal draft
Generate a short cover letter for this job. Edit before sending.
Sign in to generate an AI proposal draft.
Entrar