Summary of MiniStock architecture is the following:

Client

For best user experience, client should be able to post finely grained events to server and update changed parts.

TODO: write this

Service facade

MiniStock service publishes a WCF facade, on which the following operations are available:
  • Post an event - entities and event types are defined in plugins. Posting an event should be synchronous, returning a correlation it.
  • Check for event processing status - polling by correlation id
  • Issue queries against database

Event Dispatcher

Event Dispatcher should post events to the processor nodes. Event dispatcher should know about which processor node handles which entity and event types, and it should handle event chaining too. Event dispatcher should keep track of event processing state, which is queried by service facade.

Event Processor

Event Processor nodes handle events from a well-defined set of entities. Different entity types may be scaled out to separate processor nodes, but a single entity type cannot be processed by multiple nodes.

Event processors are also responsible for keeping current entity state in memory.

Event Persister

Event persister nodes are responsible for persisting most recent entity state into query database. If an event processor processes an event, it will be returned to event dispatcher, which dispatches the results to persister node, which saves the entity state into relational database.

Query Logic

Query logic should handle database query operations.
TODO: write this


Further reading:

Last edited Apr 4, 2012 at 6:35 AM by delzubu, version 6

Comments

No comments yet.