"Evolution of microservice architecture on Conversations API", Alexander Malinovsky

6. © 2020 TWILIO INC. ALL RIGHTS RESERVED. Organization scaling More teams to fasten the development process ○ Ability to assign ownership of the feature to particular team, spreads cross team communication ○ Decreases load on single code base, less chances to step on each others toes

9. © 2020 TWILIO INC. ALL RIGHTS RESERVED. Reliability improvements Get rid of single point of failure ○ Abusive traffic for one part of functionality doesn’t mean degradation of the whole app for customer ○ The same is applicable to potential incidents on the other Introduce better fallback mechanisms and retries ○ Smart retries for messaging functionality Have opportunity to replay events after the incident

10. © 2020 TWILIO INC. ALL RIGHTS RESERVED. Scaling and rate limiting ● Scale up only parts which are overloaded ○ Increased load of push notifications orchestration might require scale up of the whole service which might be inefficient and affect other parts of functionality ● Rate limiting should be smart ○ Fairness queues for async functionality ○ RPS limits on various operations

12. © 2020 TWILIO INC. ALL RIGHTS RESERVED. Prerequisites for microservice adoption 1. Split storages 2. Common procedures for new service creation(Paved path) 3. Cloud adoption(AWS Cloud) https://fwdays.com/event/architecture-fwdays-2021/review/migration-from-cassandra-to-dynamodb

13. © 2020 TWILIO INC. ALL RIGHTS RESERVED. Communication mechanisms ● Synchronous ○ Simple to implement ○ No additional infra costs ○ Lack of retries if service is down ○ Tight coupling between services ● Event-driven ○ Additional service to maintain(message broker) ○ Loose coupling ○ Opportunity to replay events / restore the state

14. © 2020 TWILIO INC. ALL RIGHTS RESERVED. Types of event driven architecture https://martinfowler.com/articles/201701-event-driven.html Point to take into account: max event size. For kafka by default it’s 1 MB! ● Event notification ● Event carried state transfer ● Event sourcing ● CQRS

16. © 2020 TWILIO INC. ALL RIGHTS RESERVED. Main issues with domain based split 1. Cross service requests 2. Potential inconsistencies due to lack of transactions 3. Potential issues with data replication 4. Difficult to set boundaries between the teams

18. © 2020 TWILIO INC. ALL RIGHTS RESERVED. Services decommissioning VS 1. Shared data storage 2. Shared code base which requires updates in two places 3. Complexities in testing Data cleanup service in isolation

21. © 2020 TWILIO INC. ALL RIGHTS RESERVED. Conclusions PROS 1. Introduced 1 more completely independent team + shared some features with 2 other teams 2. Better reliability for some of the features + additional rate limiting protection due to even driven nature 3. Due to independence of domains each service can scale independently and based it’s own needs CONS 1. Time for feature development not decreased(yet?) 2. Latencies increased in some cases

"Evolution of microservice architecture on Conversations API", Alexander Malinovsky

You are reading a preview.

Check these out next

"Evolution of microservice architecture on Conversations API", Alexander Malinovsky

More Related Content

Similar to "Evolution of microservice architecture on Conversations API", Alexander Malinovsky (20)

More from Fwdays (20)

Recently uploaded (20)