DevOps Case Study
Mocial set out to become a single super-app that combines the best of Facebook, Instagram, Netflix, LinkedIn and X. The first version launched as a single EC2 monolith where frontend, backend and database all lived together – creating bottlenecks in scalability, deployments and reliability. Trimsel helped Mocial replatform to a microservices architecture on Amazon EKS with modern DevOps and SRE practices.
In this case study, see how we moved from one fragile EC2 box to a production-grade platform with Codefresh CI/CD, autoscaling, observability and safer releases.


OVERVIEW

Turning a Single EC2 Monolith into a Scalable Super-app
Mocial’s vision was ambitious: offer a single platform where users can browse feeds, share media, network professionally, discover jobs and watch live content. The first implementation shipped quickly but ran everything – frontend, backend and database – inside one EC2 instance. Deployments were risky, scaling was vertical-only, and a spike in one area could impact the entire app.
Trimsel partnered with Mocial to design and implement a modern DevOps foundation. We introduced a microservices architecture on Amazon EKS, Codefresh-based CI/CD and SRE practices so that the platform could scale workloads like feeds, media, chat and notifications independently.
Looking for similar DevOps uplift? Explore our DevOps consulting services and cloud consulting offerings.
START YOUR PROJECT
Need to stabilise and scale your platform?
Request a one-to-one consultation with our DevOps team to assess your current stack and define a migration path.
Client :
Mocial (Stealth Super-app)
Industry :
Social, Media & Community
Engagement :
DevOps & Cloud Re-platforming
Cloud :
AWS (EKS, S3, CloudFront)
K +
Estimated Monthly Users*
K +
Daily Active Sessions*
+
CI/CD Pipeline Runs / Year*

THE CHALLENGE
Monolith Bottlenecks: Slow Deployments and Fragile Scale

The first version of Mocial shipped as a single EC2 instance hosting frontend, backend and database together. That helped the team move fast initially, but quickly created operational problems:
• Risky, manual deployments. Every deploy required coordinated manual steps, with no easy rollback and a real risk of downtime.
• Limited scalability. Traffic spikes from feeds, media uploads and live usage had to be absorbed by the same instance, with only vertical scaling as an option.
• Minimal observability. There were no clear SLOs/SLIs, little tracing and only basic logs, making it hard to diagnose incidents.
• Coupled teams. Because all features lived inside one codebase and deployment unit, feature teams were blocked by a shared release train.

PROBLEM FACED
A Super-app Vision Held Back by Infrastructure Limits
Mocial’s product vision was clear: one super-app that could blend social feeds, media sharing, networking, jobs and live content. But the underlying infrastructure made it difficult to sustain this vision in production.
Any spike in one feature – a trending post, a burst of live viewers, or a marketing campaign driving new sign-ups – could push CPU, memory and database connections to their limit. The team had no consistent way to measure p95 latency, error rates or saturation, and no formal SLOs or error budgets to guide rollouts and risk.
Mocial needed a modern DevOps and SRE foundation: one that could decouple services, safely increase release frequency, and give operators the visibility they needed to keep the experience stable while the product evolved.


THE SOLUTION
Microservices on EKS with Codefresh CI/CD and SRE Practices
Strangler-fig migration. We incrementally decomposed the monolith into focused services – auth, users, feed, media, notifications, chat and admin – without a big-bang rewrite.
Amazon EKS for core workloads. Each service runs as one or more deployments on EKS with horizontal pod autoscaling, pod disruption budgets and resource limits/requests tuned per workload.
Dedicated environments. Dev, QA and Production are isolated using separate namespaces and environment configs, with promotions flowing through a Git-driven pipeline.
Codefresh CI/CD pipelines. Each service has a pipeline that builds, tests, scans and deploys containers via Helm. Progressive delivery strategies (canary and blue/green) allow safe rollouts and fast rollbacks.
Observability by default. OpenTelemetry tracing, Prometheus/Grafana metrics and structured logs provide end-to-end visibility. We defined SLIs/SLOs for availability, p95 latency and error rate per service.
Runbooks & SRE workflows. Common incident scenarios are documented with playbooks and automated checks. Where possible, Codefresh can automatically roll back on SLO breach to reduce MTTR.
Cost optimisation and resilience. Node groups are right-sized; autoscaling and spot instances are used where suitable. Media is offloaded to S3 with CloudFront, and storage lifecycle policies reduce long-term cost.
Security and compliance. Secrets are managed via AWS Secrets Manager; IAM roles follow the principle of least privilege; network policies and WAF rules protect ingress.
Ongoing DevOps coaching. We worked with the Mocial engineering team to embed good Git practices, trunk-based development and a “you build it, you run it” mindset.

TECHNOLOGY
Platform & DevOps Stack
Cloud & Services





Design & Collaboration


Under the hood, the platform also makes use of AWS EKS, S3, CloudFront, managed databases, Redis caching, observability tools and Codefresh pipelines for CI/CD – forming a cohesive DevOps foundation for Mocial’s super-app roadmap.

RELATED CASE STUDIES

