This has worked very well for us, but we're starting to bump up against API limits. I'd like to move more of that data into our own DBs, but then we run into consistency issues: If a Sales Rep edits a customer's name in Salesforce, how do we keep our database consistent with that? We could build services to propagate any DB edits to the CRM and vice versa, but I don't think we have the person power to do that in a robust way.
I have to assume that many, many startups have run into the issue of needing to keep application data synced with CRM data. Any advice?
Another (dirty) option is query the updated records on a schedule and update your local database. If you see on average 20 records change a day, then just do syncs every 30 minutes so at worse you are out a short bit. Triggers are obviously superior however. This all depends no what you are using the data for and what is the impact of a stale record. Cause you could also do this once a day but then anytime an action/decision is to be taken on a specific record you hit SF database and confirm you have the latest. But for general reporting it is rare that the count can't be slightly delayed, and where it can't there are options.
Add a hook to the form itself to push the update to your system as well, again it has been awhile, but I worked on a project where this was done by another team, not for the same reason you are interested but it was possible. Basically it was similar to using a trigger but was done at the form level with a web hook, but sorry I don't know much about this methodology.
You might want to pay for an hour or two from a SF integration consultant to help give you some ideas, there are lots of options usually for this and SF is a huge product so might save you tons of time to get an expert recommendations.
I am a huge fan of not leaving your data in SF only, there are so many reasons it is better to have your data locally.
I hope this helps you, let me know if it gets you any further.