Mariusz Kotas

Posted on 20th February 2020

E-commerce information system

news-paper Case studies |

One of our customers is a well-known e-commerce company in the Czech Republic operating in a dynamic environment. The customer’s turnover was 25 billion CZK (=1 billion USD) in 2018 and growing by 20% year on year. Flexiana delivers ⅓ of the development team for this project, the rest is customer’s own development team. We are closely codeveloping as one team. Currently, we are cooperating for more than 3 years on joint development projects.

Woman with tablet and there is a ecommerce logo

The main goal of the project is to enable customer back office operations for further growth and expansion.

“I’m glad, that together we have built a team where each member is doing his best for the success of the project. From extensive discussions about architecture, through development and usability, to testing and continuous improvement of team collaboration. Cooperation with Flexiana is very beneficial for us.”

Head of ERP Development

Customer challenges

When you decide to replace main system with next-gen you should consider the motivation and goal. The goal should never be the replacement only. In order to succeed we have jointly defined following:

  • Limited Scalability – in terms of horizontal scaling – performance of the system.
  • Limited Scalability – in terms of large-scale parallel development of system features
  • No Multiplatform UI – current solution is limited to Windows only which is limitation for further expansion and better customer service
  • Costly to maintain – current solution is very matured and requires complex knowledge with long learning curve
  • Challenging to attract new developers – due to currently used technologies, it’s hard to find new members of development team
  • Knowledge and time limitation for introduction on new system – customer’s teams were busy with supporting growth on current platform, the decision was to bring capacity and expertise from our team

Microservices Architecture

The main reasons why we have chosen microservices based architecture follows:

  • Easily horizontally scalable
  • Technology agnostic
  • No single point of failure
  • Enables the continuous delivery/deployment of large, complex applications independently releasable
  • Communication (sync vs. async – REST, GraphQL, gRPC vs messaging (RabbitMQ, Kafka)
  • Infrastructure – communication (retry policy, circuit breaker), monitoring (logs, realtime)
  • Development process
  • Continuous integration (build server, Jenkins) and continuous delivery (versioning, canary deployment)

High-level architecture view

High-level architecture view

What we have delivered so far

After almost 3 years of cooperation, Flexiana team together with internal teams delivered following main deliverables:

  • Infrastructure – Kubernetes (k8s)
  • CORE Microservices (.NET)
  • API
    • Domain services – GraphQL
    • System/support services
      • frontend – REST
      • backend – gRPC
  • Orchestration (distributed GraphQL)
  • Custom Frontend – Core libraries (Angular)
  • Frontend separated as multiple micro frontends (independently deployable)
  • Canary deployments (different versions running in parallel)
  • Continuous integration and delivery
  • Monitoring
  • QA (static code analysis, unit tests, integration tests, UI, e2e tests)
  • Authentication (OpenID)
  • Authorization (static permissions, dynamic permissions)
  • Communication (Sync: REST, GraphQL, gRPC, Async: Messaging)
  • Messaging (RabbitMQ, Kafka)
  • Integration of services based on different technologies (.NET vs Java)
  • Backward compatibility

What challenges did we face?

  • MVP (Minimum viable product) – we should be better in the definition of minimal feature sets in various domains in order to deal with the complexity
  • Solution Complexity – we are still discovering unknowns in the knowledge iceberg
  • At the start of the project, we lacked enough testing environments. Now the situation is balanced with several of them: local, dev (Cannary deployment), stage/test and production).

We should always keep in mind: GO DEEP AND NARROW RATHER WIDE AND SHALLOW.