Doing some proofs of concept for the brand new microservices architecture using Spring Boot and Spring Cloud I’ve chosen few backing technologies for tests. To create serious web application we need at least a database, something for messaging and distributed session/cache. The most common choices as always come from Spring-supported technologies and my ones are PostgreSQL and MongoDB as databases (depending on if we need transactional database in the specific service or not), Redis as a distributed memory grid and RabbitMQ for messaging. Now it’d be nice to have everything working transparently under one transaction manager.
Read the full articleFew days ago I was asked to implement charts with some finance data using JS charting library, in the application working on Postgres database. There’s a lot of finance stuff in the database stored every minute and I just needed to show this data on charts.
OK, but charts are nice if you can restrict amount of your data returned from the server to some limited number of items. Returning 1000 items would both - make chart very heavy and unreadable and consume a lot of net traffic. I assumed 50 as the average number of items that are nicely displayed on such charts and are also acceptable from the traffic point of view.
Read the full articleIn the current project we faced the problem of concurrent changes to database, for the data that should be accessed sequentially. Imagine you have the customer’s bank account where he can withdraw the money. If the customer is not a person, but company, and if he can have multiple users accessing the bank application, without any locks there’s a chance for situation where two or more users depute transfers, that exceed the account balance, but because data is accessed concurrently, they both can make payoff.
Read the full article