Distributed cache
Hazelcast is a distributed cache implementation and a free open-source alternative to Oracle Coherence that also supports Write-behind and Continuous Query mechanisms, which in combination can solve your three problems.
- Use write-behind for asynchronous database writes through cache.
- Use Continuous Queries to receive real-time updates for each cache put operation.
- Hazelcast is distributed and it's very easy to start a cluster. With write-behind your scalability is limited by the number of hazelcast nodes and the amount of available memory.
Messaging
Messaging middleware is another option that can be used to address your problems.
- Leverage asynchronous queues/topics to offload database. The queues/topics would be logically partitioned in a flexible way to be able to tune load on the database. This will require development of a separate layer between messaging and the database.
- Again, use topics to subscribe for incoming orders to create an effect of continuous querying (the layer that consumes orders and persists them to the db would be responsible for sending updates).
- Many messaging broker implementations also support clustering/distribution for additional parallelisation and scalability (e.g., HornetQ).
Note that with messaging you can have high availability, reliability and scalability at the same time.
Database level
Assuming you are using Oracle as your database, you have at least the following options for your problems 1-3:
- Partitioning of tables by region/date range/client name/other category - whatever fits your particular case - will give you some room for scaling your reads/writes. If you have a lot of CPU cores available to Oracle, proper partitioning may increase performance of queries drastically on big datasets leveraging the level of parallelisation (in one project we achieved improvement from 5 hours to 10 minutes for processing of a huge dataset).
- An INSERT trigger in combination with Oracle Advanced Queuing can be used to implement continuous querying (although, an external messaging broker may work better in some cases).
- See #1.
In fact, you can think of combinations of the described above approaches to achieve the best performance and scalability for your specific case.
I have not considered migration to a NoSQL datastore, as IMO, NoSQL solutions are not the best fit for applications where data consistency is critical, which I assume is your case.