If you intend to perform a Neo4j production deployment successfully, you’ll likely think about the best application architecture to use and how you’ll operate your Neo4j Enterprise deployment at a scale. Some things you’ll need to think about should include how you intend to guarantee availability uptime, handle failures and efficiently facilitate zero downtime upgrades, which is really just the required baseline to be considered production ready. It may go without say, but to go to production without using Neo4j Enterprise is a huge risk to your applications availability.
- Using Neo4j embedded: This means you’ll be utilizing the Neo4j Java libraries and packaging it with the rest of your application code into a WAR or JAR file that is deployed to the Java server of your choice such as JBoss or Tomcat.
- Using Neo4j server: This means you’ll be utilizing the default Jetty server wrapper that is provided with Neo4j and communicating with the database over rest, which is the recommended approach for almost all applications because it keeps your database decoupled from your application and enables the two to be upgraded independently. In this architecture if you do need low-level access to the Java APIs you’ll be able to utilize unmanaged extensions that deploy directly to the Neo4j database.
- High Availability Clustering
Thanks to advancements made in SaaS and mobile, enterprises have evolved to effectively engage with their customers over the years. This connected architecture offers numerous challenges since keeping services and systems running and connected is essential.
High availability clustering is used to reduce downtime and offer consistent service when specific system components fail. High availability clusters have numerous nodes that interact and share data effectively to ensure high system scalability, availability, and reliability.
- Backup and Restoration
A backup solution is the one responsible for creating separate data copies which can be utilized in restoring back the cluster in an event of failure. The backup strategy for how much you keep and how you perform the backup is largely dependent on the size of the database on disk, but whatever the case you’ll want that restoration to be nearly immediate.
- Disaster Recovery
Disaster recovery deals with deploying to a geographically distinct location to enable your database to remain available in the event of a failure in your primary region. With multi-region failover, your Neo4j cluster will span multiple WAN (Wide Area Network) locations consisting of a primary region and a secondary failover region. In cases of failure or impairment in your primary region, your Neo4j Enterprise graph database will immediately have traffic routed to the newly elected master in the secondary region.
*To utilize a multi-region failover with the least service interruption, you’ll need to make use of a CDN service. This is essential to curb service interruption. The CDN will continue serving cached content while your site is being switch over to the secondary region.
Figuring out all of this on your own will be time consuming and challenging, which is why after having done it multiple times over the years we’ve made it a foundational component in GraphGrid Data Platform Neo4j cloud offering of production-ready Neo4j. We’ve done this because we know it’s just the expected baseline for any production application and not something you should leave to chance.